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(57) Abstract: The invention relates to a method for liansJating programmes into a system condsting of at least one first processor 
^ and a le-configarable unit. According to the method, parts of the code that are suitable for the le-configorable miit are determined 
and extracted and the lemaining code is extracted in this manner for processing by the first processoi; 
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Titel: Verfahren zur Bearbeitung von Daten 

Beschreibung 

Die vorliegende Erfindung befafit sich rait Datenverarbeitting. 
Insbesondere befa£t sich die vorliegende Erfindung mit her- 
koiranlichen, d.h. konventionellen und rekonf igurierbaren Pro- 
zessorarchitekturen sowie mit Verfahren hierfur, die eine 
Obersetzung einer klassischen Hochsprache (PROGRAMM) wie 
Pascal, C, C++, Java, etc. erraoglichen, insbesondere auf eine 
rekonf igurierbare Architektur. Insbesondere- bef aEt sich die 
vorliegende Erfindung mit der Integration und/oder engen Kopp- 
Irnig von rekonfigurierbaren Prozessoren mit Standardprozesso- 
ren, dem Datenaustausch iind der Synchronisation der Datenver- 
arbeitnng. 

Unter einer konventionellen Prozessorarchitektur (PROZBSSOR) 
werden vorliegend beispielsweise sequentielle' Prozessoren mit * 
einer von-Neumann- oder Harvardarchitektur verstanden., wie 
2.B. Kontroller, CISC-, RISC-, VLIW-, DSP-, u.a. Prozessoren 
verstanden. 
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Unter einer rekonf igurierbaren Zielarchitektur warden vorlie- 
gend Bausteine (VPU) mit wiederholt \md insbesondere 2ur Lauf- 
zeit insbesondere unterbrechxingsfrei konf igurierbarer Funktion 
und/od^r Vernetzung verstanden, insbesondere integrierte Bau- 
steine mit einer Mehrzahl von ein- oder mehrdimensional ange- 
ordneten arithmetischen und/oder logischen und/oder analogfen 
und/oder speichernden insbesondere evtl. auch grobgranularen 
Baugruppen (PAB) , die direkt oder durch ein Bussyetem mitein- 
ander verbunden sind. 

Zur Gattung dieser Bausteine zahlen insbesondere systollsche 
Arrays, neuronale Netze, Mehrprozessor Systeme, Prozessoren 
mit mehreren Rechenwerken und/oder logischen Zellen, Vemet- 
zungs- und Netzwerkbausteine wie z,B. Crossbar-Schalter, eben- 
so wie bekannte Bausteine der Gattiing FPGA, DPQA, XPUTBR, 
etc.. Hingewiesen wird insbesondere in diesem Zusaramenhang auf 
die folgenden Schutzrechte desselben Anmelders: P 44 16 881.0- 
53, DE 197 81 412.5, DE 197 81 483.2, DE 196 54 846.2-53, 
DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198.80 129.7, 
DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 
36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 
014.6, PCT/EP 00/10516, BP 01 102 674.7, DE 196 51 075.9-53, 
DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 728.9, 
DE 197 07 872.2, DE 101 39 170.6, DE 199 26 538.0, 
DE 101 42 904.5, DE 101 10 530.4. Diese sind hiermit zu Offen- 
barungszwecken vollumfanglich eingegliedert. 

Das System kann insbesondere als (Standard) -Prozessor oder 
Baugruppe ausgestaltet sein und/oder in einem Halbleiter tSy- 
atem on Chip SoC) integriert sein. 

Rekonfigurierbare Bausteine (VPUs) unterschiedlicher Gattungen 
(wie z.B. PACT XPP-Technologie, Morphics, Morphoeys, Chamele- 
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on) sind zm bestehenden technischen Umgebungen und Program- 
mlerverfahren weitgehend inkorapatibel. 

Progranune far diese Bausteine sind typisch inkompatibel zu be« 
reits bestehenden Progratranen von CPUs. Dadurch wird ein erheb- 
licher Bntwicklungsaufwand zur Programmierung erforderlich, 
z.B. besonders t^v Bausteine der Gattungen Morphics, Morpho- 
sys. Chameleon integriert bereits einen Standardprozessor 
(ARC) auf mehr oder minder rekonfigurierbaren Bausteinen. Da- 
durch stehen Ansatze fur Tools zur Programmierung zur Verfu- 
gung.. Allerdings ist nicht jede technische Omgebung fur den 
Einsatz von ARC-Prozessoren geeignet, insbesondere liegen be- 
stehende Programme, Codebibliotheken etc. oftmals f<ir beliebi- 
ge unbestimrate andere CPUs vor. 

Es hat sich in intemen Versuchen gezeigt, dafi es bestimmte 
Verfahren und ProgrammablSufe gibt, die sich besser mit einer 
rekonf igurierbare Architektur abarbeiten lassen als mit einer 
konventionellen Prozessorarchitektur. Uragekehrt gibt es auch 
seiche Verfahren und Programmablaufe/ die besser mit einer 
konventionellen Prozessorarchitektur ausgefuhrt werden kdnnen. 
Es ist dafiir wfinschenswert, ^m eine jeweilige Optimierung zu 
ermoglichen, eine Ablaufteilung vorzusehen. 

Bekannte Ubersetzungsverfahren fur rekonf igurierbare Architek- 
turen unterstutzen keine Weitergabe von Codes an beliebige 
Standard -Compiler zur Generierxang von Ob jekt codes fur einen 
beliebigen PROZESSOR. Gewdhnlicherweise ist der PROZESSOR fest 
innerhalb des* Compilers definier.t. 

Weiterhin existieren keine Scheduling-Mechanismen zur Rekonfi- 

guration der einzelnen generierten Konf igurationen fur VPUs. 

Insbesondere fehlen Scheduling-Mechanismen far die Konfigura- 

3 
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tion unabhSngiger extrahierter Telle gleichwohl wie fflr ein- 
zelne Partitionen extrahierter Telle. Entsprechende Uberset- 
zungsverfahren nach dem Stand der Technik slnd beispielsweise 
' de£xniert durcb die Dissertation itUbersetzungsmethoden tHr 
strukturprograramierbare Rechner, Dr. Markus Weinhardt, 1997*. 

Zur Partltionierung von Array-CODB sind mehrere Verfahren nach 
dem Stand der Technik bekannt, z. B. Joao M. P. Cardoso, « Com- 
pilation of Java*" Algorithms onto Reconfigurable Computing Sy- 
stems with Exploitation of Operation-Level Parallelism*/ Ph. 
D* Thesis Universidade T^cnica de Lisboa (IfTL) , 2000. 

Diese Verfahren sind jedoch in keine kompletten Compilersyste- 
me eingebettet. Weiterhln setzen die Verfahren die vollst&ndi- 
ge Steueriing der Rekonf iguratlon durch einen Hostprozessor 
voraus, was einen erheblichen Aufwand bedeutet. Die Partitio- 
nierungsstrategien sind fur FPGA-basierende Systeme ausgelegt ' 
und entsprechen daher keinem echten Prozessormodell. 

Die Aufgabe dieser Erfindixng besteht darin, Neues fflr die ge- 
werbllche Anwendung bereitzustellen. 

Die Losung dieser Aufgabe wird in unabhSngiger Form bean- 
sprucht- Bevorzugte AusfOhrungen flnden slch in den Unteran- 
spriichen. 

Bin rekonflgurlerbarer Prozessor (,VPU) wird somlt in eine 

technische Dmgebung eindeslgned, die. einen Standardprozessor 

(CPU) besitzt, wie beispielsweise einen DSP, RISC, CISC- 

Prozessor oder (Mikro) -Kontroller aufweist . Das Design kann 

erfindungsgemas derart erfolgen, dass eine einfache und lei- 

stungsfahige Anbindung besteht. Eiq sich ergebender Aspekt ist 

die einfache Programmierbarkelt des entstehenden Systems. Die 

4 
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Weiterverwendimg bestehender Programme der CPU sowie die Code- 
kompatibilitat und die einfache Integration der VP17 in die be-- 
stehenden Programme finden Berucksichtigung. 

Bine VPU (oder ohne jeweils besonders erwShnt zu werden, meh* 
rere VPUs) wird derart mit einer bevorzugten CPU (oder ohne 
jeweils besonders erwShnt zu werden, mehreren CPUs) gekoppelt, 
dass sie die Stelle und Funktion eines Coprozessors (bzw. meh- 
rerer wahlweise ansprechbarer Coprozessoren) einnimmt. Die 
Funktion ermoglicht die einfache Einbindung in bestehende Pro* 
grammcodes entsprechend den bereits existierenden Nethoden zum 
Utngang mit Coprozessoren nach dem Stand der Technik. 

Der erfindungsgemSfie Datenaustauech zwischen CPU und VPU kann 
mittels Speicherkopplung und/oder lO-Kopplung erfolgen. CPU 
und VPU konnen samtliche Ressourcen teilen, in besonderen Aus- 
gestaltungen ist es auch moglich, dass CPU xind VPU nur eihen 
Teil der Ressourcen gemeinsam verwenden und andere Ressourcen 
jeweils eatplizit \md/oder exclusive fiir eine CPU Oder VPU zur 
VerfQgxing stehen. 

tJta einen Datenaustausch durchzufiihren, konnen Datensatze 
und/oder Konf igurationen in jeweils besonders dafiir vorgesehen 
Speicherbereiche kopiert bzw. geschrieben/gelesen werden 
und/oder entsprechende Basisadressen gesetzt werden, dass die- 
se auf die jeweiligen Datenbereiche zeigen. 

Zur Steuerung des Coprozessors wird bevprzugt ein Datensatz 

vorgesehen, der beispielsweise die Grundeinstellungen einer 

VPU beeizihaltet, wie beispielsweise bestimmte Basisadressen. 

Desweiteren konnen Statusvariablen zur Ansteuerung und Funkti- 

oiissteuerung einer VPU durch* eine CPU sowie far Riickmeldungen 

einer VPU an eine CPU vorgesehen sein. Der Datensatz kann liber 

5 
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einen gemeinsamen Speicher (RAM) und/oder Ober einen gemeinsa- 
men peripheren Adressraum (10) ausgetauscht werden* 

2ur Synchronisation der CPU und VPU kdnnen elnseitlg Oder ge- 
genseitig wirkende Interruptverfahren (die z.B. durch Signal- 
transfer uber insbeeondere dedizierte bzw. hierffir ausgebilde- 
te Interrupt lei tungen und/oder Interrupteingange realisiert 
sind) vorgesehen sein und/oder die Synchronisation erfolgt 
mittels Pollingverfahren. Weiterhin konnen Interrupts zur Syn- 
chonisation von Daten- und/oder DMA-Transfers verwendet wer- 
den. 

In einer besonders zu bevorzugenden Ausgestaltung wird eine 
VPU durch eine CPU gestartet und arbeitet danach bevorzugt un- 
abhangig die Applikation ab. 

Besonders leistungsfahig ist ein bevorzugter Aufbau, bei wel- 
Chen die verwendete VPU eigene Mechanismen zum Laden und Kon- 
trollieren von Konf igurationen vorsieht. Zur Gattung dieser 
VPUs gehdren beispielsweise PACT XPP und Chameleon. Die erf in- 
dungsgemaSen Schaltungen ermoglichen ein Verfahren zum Betrieb 
derart, dass die Konf igurationen der VPU zusamraen mit dem aus- 
zufflhrenden Programm der CPU in einen Speicher geladen werden. 
Die CPU kann wfthrend der Ausf^lhrung des Programmes die VPU auf 
die Speicherstellen verweisen (z.B. durch Angabe der Adressen 
Oder Pointer) , die die jeweils auszufOhrenden Konfigxirationen 
beinhalten. Die VPU kann daraufhin die Konfigurationen selb- 
standig und ohne weitere Einflufinahroe durch die CPU laden. Die 
AusfChrung startet sofort oder ggf . durch eine. zusatzliche In- 
formation (z.B. Interrupt und/oder Start Befehl) durch die 
CPU. 



6 



wo 02^03532 PCT/EP02/06865 

In einer besonders bevorzugten Erweiterung kann die VPU selb- 
standig innerhalb eines Speichers Daten lesen und schreiben. 



In einer besonders bevorzugten Erweiterung kann die VPU eben- 
falls selbstandig neue Konf igurationen aus dem Speicher laden 
und sich bei Bedarf neu konfigurieren, ohne dass es eines wei- 
teren Einflusses durch die CPU bedarf.. 

Diese Ausgestaltungen ermoglichen einen weitestgehend von CPUs 
unabhangigen Betrieb von VPUs, Lediglich ein Synchronisations- 
austausch zwischen CPU und VPU, der bevorzugt bidirektional 
stattf inden kann, sollte zusatzlich vorgesehen werden, um die 
Datenverarbeitungen und/oder KonfigurationsausfQhrungen auf- 
einander abzustimmen. 

Es wurde weiter erkannt, daS Verfahren zur Datenverarbeitung 
bevorzugt so ausgelegt werden kdnnen und/oder sollen, dafi je- 
weils fur die rekonf igurierbare Zielarchitektur (VPU) beson- 
ders geeignete Teile (VPU-CODE) des zu ubersetzenden Program- 
mes identif iziert und extrahiert werden, um eine besonders ef- 
fiziente Datenverarbeitung zu ermoglichen. Diese Teile sind 
entsprechend zu partitionieren und die Konf iguration der ein.- 
zelnen Partitlonen ist in ihrer zeitlichen Reihenfolge zu 
steuem. 

Di.e verbleibenden Teile des Programmes kdnnen auf eine konven- 
tionelle Prozessorarchitektur (PROZESSOR) xibersetzt werden. 
Dies geschieht bevorzugt dergestalt, dafi diese Teile als Hoch- 
sprachencode in einer Standard-Hochsprache (z. B. ANSI C) der- 
art ausgegeben werden, daS ein gewohnlicher (ggf . bereits exi- 
stierender) Hochsprachencompiler diese ohne weiteres verarbei- 
ten kann. 
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Weiterhin sei angemerkt, dafi die Verfahren auch auf Gruppen 
von mehreren Bausteinen angewendet werden k6nnen. 



Insbesondere kann eine Art "Double-Buf fering« zur besonders 
einfachen und zugleich schnellen Rekonfiguration angewendet 
werden, in welchem eine Mehrzahl von VPUs vorgesehen sind, wo- 
bei ein Tell der VPUs zu einer Zeit rekonf iguriert werden 
kann, zu welcher ein anderer Teil rechnet und moglicherweise 
ein Weiterer etwa inaktiv sein kann. Die Daten-, Trigger-/ 
Statusverbindungen etc. werden zwischen der Mehrzahl von VPUs 
geeignet ausgetauscht xxnd ggf , durch adressierte Buase 
und/oder Multiplexer/Demultiplexer entsprechend der aktuell 
aktiven und/oder zu rekonf igurierenden VPOs verschaltet. 

Ein Vorteil dieses Verfahrens liegt darin, dafi bestehender 
Code, der far einen beliebig^n PR02ESS0R geschrieben wurde, 
unter Einbeziehung einer VPU weiterverwendet werden kann und 
keine oder nur vergleichsweise geringe Modif ikationen durchge- 
fuhrt werden miissen. Die Modif ikationen kdnnen zudem schritt- 
weise erf olgen, wobei nach und nach immer mehr Code von deni 
PR02ESS0R auf die VPU ubertragen werden kann. Das Projektriai- 
ko sinkt tind die Uberschaubarkeit steigt wesentlich an. Es 
wird darauf hingewiesen, dciS einer derartigen sukzessive fiber- 
tragung von immer mehr Aufgaben auf die VPU, d.h. auf das in- 
tegrale multidimensionale partiell rekonf igurierbaren insbe- 
sondere grobgranulare Feld an Elementen, eine besondere Bedeu- 
tung fflr sich hat und fOr sich als erfinderisch angesehen wird 
aufgrund seiner gravierenden Vorteile bei der Systemportie- 
rung. 

Weiterhin kann der Programmierer in seiner gewohnten Entwick- 
lungsumgebung arbeiten und muE sich nicht auf eine neue, mog- 
licherweise fremde Entwicklungsumgebung einstellen. 

8 
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Ein erster wesentlicher Aspekt der vorliegenden Erfindung ist 
darin zu sehen, daS ein PROZESSOR derart mit einer oder mehre-. 
ren VPU(s) verbunden wird, daS ein effizienter Informations- 
austausch, insbesondere in Form von Daten- und Statusinforma- 
tion m6glich ist. 

Der Anordnung eines herkommlichen Prozessors und einea rekon- 
figurierbaren Prozessors, dergestalt, daS ein Austausch von 
Daten- und/oder Statusinformation zwischen denselben w§hrend 
der Abarbeitung eines oder mehrerer Programme moglich ist 
und/oder ohne da& insbesondere die Datenverarbeitung auf dein 
rekonf igurierbaren Prozessor und/oder dem herkommlichen Pro- 
zessor signifikant unterbrochen werden muS, sowie der Ausbil- 
dung eines derartigen Systems, wird gleichfails fixr sich Be- 
deutung zugemessen. 

Es kdnnen zunSchst beispielsweise eines oder alle der folgen- 
den Verbindungsverfahren und/oder -mittel verwendet weirden: 

a) Shared-Memory 

b) Netzwerk (beispielsweise Bussysteme wie z.B. PCI -Bus, Se- 
rielle Busse wie z.B. Ethernet) 

c) Kopplwg an einen intemen Registersatz oder mehrere' in- 
teren Registersatze 

d) andere Speichermedien (Festplatte, Flash-ROM, etc.) 

Prinzipiell kann auch die VPU und/oder CPU selbst&ndig ohne 
Zuhilfenahme eines DMAs auf den Speicher zugreifen. Der ge- 
meinsame Speicher kann insbesondere auch als Dualport- oder 
Multiportspeicher ausgestaltet sein. Dem System kdzmen weitere 
Baugruppen zugeordnet werden, insbesondere k6nnen rekonf igu- 
rierbare FPGAs eingesetzt werden, um eine feingranulare Verar- 
beitung von einzelner Signale oder Datenbits zu ermdglichen 
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und/oder flexible adapt ierbare Interface {z.B. diverse seriel- 
le Schnittstellen (V24, USB, etc.), diverse parallele Sclinitt' 
stellen, Pestplattenschnittstellen, Ethernet, Telekommunikati- 
onsschixittstellen (a/b, TO, ISDN, DSL, etc) ) aufbauen zu k6n- 
nen. 

Der Aufbau einer VPU ist beispielsweise bekannt aus den o. g. 
zitierten Anmeldungen. Versuche zu altemativen Bausteindef i- 
nitionen sind beispielsweise unter dem Namen Chameleon gefiihrt 
worden, VPUs lassen sich auf unterschiedliche Weise in ein Sy- 
stem integrieren. Ein AnschluS an einen Hostprozessor ist bei- 
spielsweise indglich. Je nach Verfahren kann der Hostprozessor 
die Konfigurationskontrolle (HOSTRECONF) mit ubernelimen (z. B. 
Chameleon) Oder, z. B., eine dedizierte Einheit (CT) zur 
Steuerung der (Re)Konfig[uration bestehen. 

Entsprechend generiert der tJbersetzer getiiaB dem beschriebenen 
Verfahren die Steuerinformation fQr die Rekonfiguration fur 
eine CT und/oder einen HOSTRECONP. 

Hs kann nun das Obersetzungsprinzip derart ausgestaltet sein, 
dafi aus einem PROGRAMM mittels eines PRAPROZESSORS die Teile 
extrahiert werden, die sich auf die jeweils bestimmte(n) 
VPU(s) effizient und/oder sinnvoll abbilden lassen. Diese Tei- 
le werden in ein fur VPUs geeignetes Format trans formiert 
(NML) und dann weiter in einen Objektqode libersetzt. 

Der verbleibenden Code und/oder der* extrahierte Code wird er- 

fahrungsgeraSiS an oder bezCiglich der Stelle der durch die Ex- 

traktion fehlenden Code-Teile urn einen Interface -Code erwei- 

tert, der entsprechend der Architektur des Zielsys terns die 

Kommunikation zwischen PROZESSOR (en) und ypu(s) steuert. Der 

verbleibende und ggf . erweiterte Code kann bevorzugt 
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trahiert werden sollen. Beispielsweise kann dies folgeixdenna- 
Sen erfolgen: 



Code 

# START_EXTRACTIOM 

Zu extrahierender Code 

# END_EXTRACTION 

Code 

all START_EXTRACTION* kennzeichnet den Beginn eines zu extra- 
hierenden Codes* 

„H END^EXTRACTION*^ kennzeichnet das Ende eines zu. extrahie- 
renden Code. 

In einem solchen Fall ist die Einheit zur Utnsetzung des Pro- 
gxami&s ^n Konfigurationscodes dazu ausgebildet, die Hints be- 
ziehungsweise Umsetzungsvorg6d>en zu erkennen. 

£s ist auch mdglich, dal^ zur Extraktion durch Aufruf von NML- 
Routinen* Telle des PROGRAMMES direkt in NML implementiert wer- 
den und in die imL.TRoutinen durch Aufrufe (calls) gesprungen 
wird. Beispielsweise erfolgt dies derart: 

a) NML-Code 

proc.ed\2re EXAMPLE 
begin 

end 
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b) PROGRAMM Code 
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Code 

call EXAMPLE // Aufruf des NML-Codes 

Code 



In diesem Fall ist die Einheit zur Umsetzung dazu ausgebildet, 
NML-Prograiiunteile, das heil^t Prograramteile zur Ausfuhrung in 
und/oder auf einem rekonf igurierbaren Array in ein groSeres 
Programm einzubinden. 

Es ist weiter altemativ und/oder zusatzlich eine Extraktion 
aus einer objektorientierten Klasse mdglich. Fdr eine VPU ge- 
eigne te Makros werden als Klasse in der Klassenhierarchie ei- 
ner objektorientierten Programmiersprache definiert. Die Ma- 
kros kSnAen da*bei- durch Annotation derart gekennzeichnet sein, 
dafi sie als far eine VPD bestimmte Codes erkannt iind entspre- 
chend * auch in hdheren Hierarchien der Sprache • weiterverar- 
beitet werden, 

Innerhalb eines Makros ist bevorzugt eine bestimmte Vemetzung 
und/oder \tobildung durch das Makro vorgegeben, die sodann die 
Abbildung des Makros auf die VPU bestimmt, 

Durch die Instantiierung und Verkettung der Klasse entsteht 
eine Implementierung der Funktion, bestehend aus mehreren Ma- 
kros auf der VPU. Mit anderen Worten definiert die Instantiie- 
rung \ind Verkettung der Makros die Abbildung und Verne tzvmg 
der einzelnen Operationen aller Makros auf der VPU und/oder 
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ggf . die Vernetzung und/oder den Datenaustausch zwiechen VPU 
und CPU. 

Die Interfacecodes werden bei der Inst ant iierung hinzugefugt. 
Die Verkettung beschreibt das detaillierte Mapping der Klaase 
auf die VPU. 

Eine Klasse kann beispielsweise auch als ein Aufruf einer Oder 
mehrerer NML-Routinen gebildet werden. 

a) Klassen-Code 

class EXAMPLE 
begiii 

end 

b) PROGRAMM Code 
Code 

EXAMPLE varO // Instantiierung der Klasse 

Code 

Es ist weiter auch eine Extraktion durch Analyse mSglich. 
Durch an die jeweilige VPU angepaSte Analysemethoden werden 
Teile innerhalb des PROGRAMMES erkannt, die effizient und/oder 
sinnvoll auf die VPU abbildbar sind. 
Diese Teile werden aus dem PROGRAMM extrahiert. 
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Eine beispielsweise far viele VPUs geeignete Analysemethode 
ist der Aufbau von DatenfluS- und/oder Kontrollf luBgraphen aus 
dem PROGRAMM. Diese Graphen konnen hinsichtlich ihrer m6gli- 
Chen Partitionierung land/oder Abbildung auf die Ziel-VPU auto- 
mat isch untersucht werden. In diesem Fall warden die Teile der 
generierten Graphen bzw. die entsprechenden PROGRAMMTEIIiE, ex- 
trahiert, die sich hinreichend gut partitionieren und/oder ab- 
bilden lassen. Hierzu kann eine Partitionierbarkeits- imd/oder 
Abbildbarkeitsanalyse erfolgen, die die jeweilige Eigenschaft 
bewertet Entsprechend dieser Bewertung erfolgt dann die Parti- 
tionierung und Extraktion der Programinteile auf die VPU, sowie 
das Einfahren der vorgesehenen Interfaces. . 

Bs soli ausdr^cklich auf die in der Patentanmeldung DE 101 39 
170.6 beschriebenen Analysemethoden verwiesen werden, die bei- 
spielsweise zur Anwendung koramen konnen. Die vorerwahnte An- 
meldung ist zu Of fenlegungszweckung vollumfanglich eingeglie- 
dert. 

Eine mogliche Analysemethode ist auch durch Brkennung bestimm- 
ter Datentypen gegeben. 

Unterschiedliche Datentypen eignen sich mehr oder weniger gut 
fur die Bearbeitung auf einer VPU. Beispielsweise ist eine 
komplexe Pointer- Ari thine tik, bzw/eine point erbasierende Da- 
tenadressierung (pointer) schwer auf eine VPU abbiidbar, wah- 
rend sich Arrays (array) sehr gut abbilden lassen.. 

ErfindungsgemSfi k6nnen daher weitgehend autoraatisch oder manu- 
ell die jeweils geeigneten Datentypen und zumindest wesentli- 
che Teile von deren Datenverarbeitung auf eine vpa abertragen 
und entsprechend extrahiert werden. Die Extraktion erfolgt da- 
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mit im Ansprechen auf das Auftreten bestimmter Datentypen 
und/oder Datenoperationen. 



Es soil erwahnt warden, daS zusatzliche, den Datentypen zuge- 
ordnete Parameter weitere Hinweise zur Bestimmung der Ausfiihr- 
barkeit und/oder Ausf^ihrungsperformance auf einer VPa geben 
kdnnen und daher maSgeblich zur Extraktion mitverwendet werden 
k5nnen. Beispielsweise spielt die Gr6iSe von zu berechnenden 
Arrays elne wesentliche Rolle. £s lohnt sich zuineist nicht, 
kleine Arrays auf einer VPU zu berechnen, da hier der Synchro- 
nisations- und Datenaustauschaufwand zvischen CPU und VPU zu 
hoch sein kann. Einschrankend ist aber dabei wiederum zu er- 
wahnen, dafi kleine Arrays, die innerhalb einer Schleife beson- 
ders hiufig verrechnet werden, sich dennoch sehr gut fUr VPUs 
eignen, insofem die Schleife weitestgehend komplett auf der 
VPU berechnet wird. GroSe Arrays konnen dagegen zuraeist ohne 
weiteres auf einer VPU besonders performant berechnet werden. 

Weiterhin soil erwahnt werden, dafi besondere Datentypen durch 
einen besonders angepaifiten Compiler oder ggf . durch einen An- 
wender (2. B. mittels TYPE in Pascal) erstellt werden konnen, 
die sich besonders fur VPUs eignen und deren Datenverarbeitung 
dann auf einer VPU ausgeftihrt wird, 
Beispielsweise kdnnen folgende Datentypen bestehen: 
TYPE streaml of Byte [] ; 
TYPE stream2 of Byte t0..255; 

Stream definiert einen Datenstrom (stream)* von in der Regel 
groEer,. ggf. nicht vorbekannter und/oder unendlicher Lange. • 
Streaml hatte hier eine nicht vorbekannte LSnge. Beispielswei- 
se konnte ein mit diesem Datentyp programmierter FIR-Pilter 
(oder z. B. eine PPT oder DOT) automat isch - und ggf ausge- 

walzt - auf eine VPU abgebildet werden. Die Rekonf iguration 
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erfolgt dann typisch und bevorzugt im Ansprechen auf andere 
Mechanismen als den Datenstromverlauf , z.b. durch Zahler, Ver- 
gleicher, CT-gesteuert und/oder durch Time-Out. Soli hierbei 
etwa eine Wave« oder andere Rekonfiguration ausgeldst werden, 
so kann diese iiber eine durch vorgenannte Methoden veranlalSte 
Kennzeichnung eines Datenpaketes, insbesondere Datenbytes^ als 
ein letztes zu seln erfolgen um nach uhd/oder mit dem Durch- 
lauf dieses als letzes Datenpaket gekeimzeichneten Datenpake- 
tes die Rekonfiguration axzszuldsen. 

stream2 def iniert einen Datenstrom der Lange von hier 256 
Byte, der wie strearal behandelt werden kann, jedoch die Eigen- 
schaft aufweistr nach 256 Byte zu enden und damit nach Beendi- 
gung moglicherweise eine Rekonfiguration im Sinne der vorab 
zitierten Patente selbigen Anmelders auslosen kann. Insbeson- 
dere kann eine Wave-Rekonf iguration (z. B- nach DE 197 04 
728.9, DE 199 26 538.0, DE 102 06 857.7, DE 100 28 397.7) mit 
dem Eintreffen des letzten Daten-Bytes ausgeldst werden und 
mit der Verarbeitung dieses letzten Daten-Bytes die jeweilige, 
das Byte verarbeitende PAE rekonf iguriert werden. 

Eine f^ir die implement ierte VPU geeignete Obersetzung des ex- 
trahierten Codes nach NML kann bevorzugt durchgefuhrt werden. 

Fur datenf lufiorientierte VPDs kann beispielsweise autpmatisch 
ein Datenflufi- und/oder Kontrollf lulSgraph aufgebaut werden. 
Die Graphen werden dann in NML- Code ubersetzt. 

Kntsprechende Code-Teile wie z. B. Schleifen konnen mittels 

einer Datenbank (Lookup) Obersetzt werden oder gewohnliche 

Transformationen konnen durchgefuhrt werden. Filx Codeteile 

k6nnen auch Makros vorgesehen sein, die dann gemaS den in vor- 

genannten Anraeldungen offenbarten IKR weiterverwendet werden. 
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Ebenfalls kann die Modular! sierung nach PACT13, Fig. 28 ixnter- 
stutzt werden. 

Gegebenenfalls kann bereits das Abbilden auf die VPU bzw. des- 
sen Vorbereitung erfolgen, beispielsweise mittels der Durch- 
fOhrung des Plazierens der benotigten Ressourcen tmd des Rou- 
tens der Verbindungen (Place and Route) . Dies kann zuia Bei- 
spiel nach per se bekannten Regeln des Plazierens und Routens 
geschehen. 

Es ist auch mdglich, mittels einer automatischen Analysemetho- 
de den extrahierten Code und/oder den libersetzten NML-Code auf 
seine Verarbeitungsef f izienz bin zu analysieren. Dabei ist die 
Ana ly seme thode bevorzugt so gewdhlt, dalS der Interface-Code 
und die daraue entstehenden Performanceeinfliisse an geeigneter 
Stelle mit in die Analyse einflieSen. Geeignete Analyseverfah- 
ren sind insbesondere in den vorgenannten Anmeldungen der vor- 
liegenden Anmelderin beschrieben. 

Gegebenenfalls wird die Analyse durch eine koraplette Uberset- 
zung und Implementierung auf dem Hardware-System durchgefiihrt, 
indem das PROGRAMM ausgeftihrt und mit geeigneten Methoden, wie 
sie beispielsweise nach dem Stand der Technik bekannt sind, 
vermessen wird. 

Es ist weiter moglich, daS basierend auf den durchgef\lhrten 
Analysen, verschiedene durch die Extraktion fur eine VPU ge- 
wahlte Telle als ungeeignet identif iziert werden kdnnen. Umge- 
kehrt kann die Analyse ergeben, dafi bestimmte, f\ir einen PRO- 
2ESS0R extrahierte Telle zur Ausfahrung auf einer VPU geeignet 
waren. 
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Eine optionale Schleife, die nach der Analyse basierend auf 
geeigneten Entscheidungskriterien zurdck in den Extraktions- 
teil fuhrt, urn diesen mit entsprechend der Analyse angepaSten 
Extraktionsvorgaben emeut auszuf^ihren, ermoglicht die Opti- 
mierung des Ubersetzungsergebnisses. Man hat somit eine Itera- 
tion. Dieses Vorgehen ist bevorzugt. 

Eine Schleife kann an mehreren unterschiedlichen Stellen in 
den Compilerlauf eingebracht sein. 

Der erhaltene NML-Code ist bei Bedarf entsprechend den Eigen- 
schaften der verwendeten VPU zu partitionieren, d.h. in ein- 
zelne Telle zu zerlegen, die auf jeweils in die vorhandenen 
Ressourcen abgebildet werden konnen.. 

Eine Vielzahl derartiger Mechanismen, insbesondere auf Gra- 
phenanalyse basierende, sind nach dem Stand der Technik per se 
bekannt. Eine bevorzugte Variante basiert jedoch auf der Ana- 
lyse der Progrannnsourcen tind ist \inter dem Begrif f temporal 
Partitioning bekannt. Dieses Verfahren ist in der genannten 
PHD-Thesis von Cardoso beschrieben, die zu Of f enbarungszwecken 
vollumfinglich eingegliedert wind. 

Partitionierungsverfahren gleich welcher Art sind entsprechend 

des verwendeten VPU-Types zu adaptieren. Liegen VPUs vor, die 

die Speicherung von Zwischenergebniss^n in Register und/oder 

Speicher zulassen, ist durch die Partitionierung die Einbln- 

dung der Speicher zur Speicherung von Daten und/oder Zustanden 

zu berQcksichtigen. Die Partitionierungsalgorithmen (z. B, die 

temporale Partitionlertmg) sind entsprechend zu adaptieren. 

Gewohnlicherweise wird die elgentliche Partitionierung und das 

Scheduling durch die genannten Patente jedoch erheblich ver- 

einfacht xmd erst sinnvoll ermdglicht. 
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Mcmche VPUs bieten die Mdglicbkeit der differentiellen Rekon- 
figuration « Diese kann angewendet werden, wenn nur verhSltnis- 
miSig wenige Anderungen innerhalb der Anordnung der PAEs bei 
einer Rekonf iguration notwendig werden. Mit anderen Worten 
werdexi nur die Verdndermgen einer Konf iguration gegenOber der 
aktuellen Konfiguration rekonfiguriezi: . Die Partitionierung 
kann in diesem Fall dergestalt sein, dafi die auf eine Konfigu- 
ration folgende, gegebenenfalls dif ferentielle Konfiguration 
nur die notwendigen Rekonf igurationsdaten enthalt ;xnd keine 
vollstandige Konfiguration darstellt. Es ist moglich, den Kon- 
figurationsdatenoverhead zu Analysezwecken bei der Beurteilung 
der Aufteilungsef f izient mit zu berCLcksichtigen. 

Die Schedulingmechcinismen fur die partitionierten Codes konnen 
derart erweitert werden, daS das Scheduling durch Ruckmeldun- 
gen der VPU an die jeweils rekonf igurierende Einheit (CT 
und/oder HOSTRECONF) gesteuert wird. Insbesondere wird dabei 
bei der Partitionierung die sich daraus ergebende Mdglicbkeit 
der bedingten Ausftlhrung, d. h. der expliziten Bestimmung der 
nachfolgenden Partition durch den Zustand der aktuellen Parti- 
tion genutzt- Mit anderen Worten ist es mdglich, die Partitio- 
nierung derart zu optimieren, dafi bedingte Ausf uhrungen ' wie z. 
B. IP, CASE etc. beriicksichtigt werden. 

Werden VPUs verwendet, die die Fahigkeit besitzen Statussigna- 

le zwischen den PAEs zu ^ibertragen, wobei PAEs auf die jeweils 

tibertragenen Zustande reagieren und/oder diese mitverarbeiten, 

kann innerhalb der Partitionierung und des Schedulings zudem 

die bedingte Ausfiihnmg innerhalb der Anordnung der PAEs, also 

ohne die Notwendigkeit einer vollstandigen oder teilweisen Re- 

konfiguration aufgrund eines geSnderten bedingten Pro- 

grantmablauf s, berdcksichtigt werden. 
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Weiterhin kamn das Scheduling die Mdglichkeit des Vorladens 
von Konf igurationen wShrend der Lauf zeit einer cinderen Konfi- 
guration untersttitzen. Dabei konnen mehrere Konf igurationen 
mdglicherweise auch spekulativ vorgeladen werden, d. ohne 
daE sichergestellt ist, daS die Konf igurationen uberhaupt be- 
notigt werden. Durch Selektionsmechanismen konnen dann zur 
Laufzeit die zu vervendenden Konf igurationen ausgewahlt werden 
(siehe auch Beispiel MLS in DE 100 50 442.6, EP 01 102 674.7) 

Sine zus^tzliche oder alternative Variante sieht vor, dass die 
Datenverarbeitung innerhalb der an die CPU gekoppelten VPU ex- 
akt gleichviele Takte benotigt, wie die Datenverarbeitung in- 
nerhalb der Rechenpipeline der CPU. Insbesondere bei modemen 
Hochleistiuigs-CPUs mit einer Vielzahl von Pipelinestufen (>20) 
kaiui dieses Konzept ideal eingesetzt werden. Der besondere 
Vorteil ist, dass keine besonderen Synchronisationsmechanismen 
wie z.B. RDY/ACK notwendig sind und/oder keine Anpassung von 
Opcodes zur Registersteuerung erforderlich ist. Der Conpiler 
hat bei diesem Verfahren sicherzustellen, dass die VPU die er- 
forderliche Anzahl an TcJcten einh§lt und ggf . die Datenverar- 
beitung durch das Einfugen von Verzdgerungsstufen wie z. B. 
einen Fall-Through FIFOs auszxibalancieren wie er in anderen, 
vorerwahnten Anmeldungen beschrieben ist. 

Der ausgegebene Code ist tiblicherweise vollst§ndig und bevor- 
zugt ohne weitere Bingriffe auf den jeweils nachfolgenden Com- 
pilem verarbeitbar. Gegebenenfalls kdnnen Compilerf lags \md 
Constraints zur Steuerung nachfolgender Compiler generiert 
werden, wobei der Anwender falls gewiinscht. optional eigene 
Vorgaben hinzufugen ujid/oder die generierten Vorgaben modifi- 
zieren kann. Die nachfolgenden Compiler benotigen keine we- 
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sentlichen Modifikationen, so daS per se bekannte Standard- 
Tools prinzipiell einsetzbar sind. 

Das vorgeachlagene Verfahren eignet sich somit beispielsweise 
insbesondere als Praprozessor bzw. Praprozessorverfahren vor 
Compilem und Bntwicklungesystemen. Es soli aber ausdrftcklich 
erwAhnt warden, dafi prinzipiell anstatt imd/oder zusaramen mit 
den zuvor beschriebenen Obersetzers auch Compiler nach PACTll 
eingebimden warden konnen. 

An die beschriebene Architektur, insbesondere direkt an die 
VPU kann ein FPGA gekoppelt sein, um f eingreuiulcure Datenverar- 
beitung zu ermoglichen und/oder ein flexibel adaptierbares In- 
terface (z.B. diverse serielle Schnittstellen (V24, USB, 
etc.), diverse parallele Schnittstellen, Festplattenschnitt- 
stellen, Ethernet, Telekommunikationsschnittstellen (a/b, TO, 
ISDN, DSL, etc)) zu weiteren Baugruppen zu ermdglichen. 
Der FPGA kann dabei aus der VPU-Architektur, insbesondere 
durch die CT, und/oder durch die CPU konfiguriert werden. Der 
FPGA kann statisch, also ohne Rekonfiguration zur Laufzeit 
und/oder dynamisch, also mit Rekonfiguration zur Laufzeit, be- 
trieben werden. 

Es wurde bereits das Vorsehen eines Interface -Code angespro- 
chen. Der Interface -Code, der in den extraihierten Code einge- 
setzt wird, kann durch unterschiedliche Verfahren vorgegeben 
werden. Bevorzugt wird der Interface- Code in einer DatenbanJc 
abgelegt, auf die zugegriffen wird. Die Binheit zur Umsetz\ing 
kann so ausgebildet sein, daiS sie eine Auswahl, etwa des Pro- 
gratnmierers, beriick'sichtigt , bei der beispielsweise durch Hin- 
weise im PROGRAMM oder durch Compilerf lags der passende Inter- 
face-Code ausgewShlt wird. Dabei kann ein fdr das jeweils ver- 
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wendete Implementierungsverfahren des VPU/CPU- Systems geeigne- 
ter Interface-Code gewahlt werden.. 



Die Datenbank selbst kann durch unterschiedliche Methoden auf- 
gebaut und gewartet werden. Einige Beispiele sollen zur Ver- 
deutlichung der Moglichkeiten angeftort warden: 

a) Der Interface -Code kann vom Lieferanten des Compilers fflr 
bestimmte Verbindxmgsverfahren zwischen VPD und CPa(s) 
vorgegeben werden. Dies kann bei der Organisation der Da- 
tenbank berucksichtigt werden, indem entsprechende Spei- 
chermittel far diese Angaben bereitgehalten werden. 

b) Der Interface -Code kann vom Benutzer, der den Systemaufbau 
bestimmt hat, selbst geschrieben oder aus bestehenden 
(Beispiel-) Interface -Code modifiziert und der Datenbank 
zugefugt werden. Das Datenbankmittel wird hierzu bevorzugt 
benutzermodifizierbar gestaltet, um dem Benutzer die Da- 
tenbcuikmodifikation zu ermoglichen. 

c) Der Interface-Code kann von eine Entwicklungssystem/ mit 
dem beispielsweise der Systemaufbau des VPU-CPU-Systems 
geplant und/oder beschrieben und/oder get est et wurde, au- 
toraatisch generiert werden. 

Der Interface-Code ist gewohnlicherweise bevorzugt derart ge- 
staltet, dafi er den Anf orderungen der Programmiersprache ent- 
spricht, in der der extrahierte Code vorliegt in den der In- 
teriace-Code eingefugt werden soil. 

Debugging und Integration der Toolsets 

In die Interface- Codes konnen Kommunikationsroutinen einge- 
fxihrt werden, um die unterschiedlichen Entwicklungssysteme fflr 
PROZESSOR und VPU zu synchronisieren. Insbesondere kann Code 
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far die jeweiligen Debugger (z. B. nach PACTll) aufgenotranen 
werden. 



Der Interface -Code ist so ausgebildet, dafi er den Datenaus- 
tausch zwischen PROZESSOR und VPU ermdglicht xxnd/oder steuert. 
Er ist daher eine geeignete und bevorzugte Schnittstelle, urn 
die jeweiligen Bntwicklungssysteme und Debugger zu steuern. Es 
ist beispielsweise moglich, einen Debugger ffir den PROZESSOR 
Bolange zu aktivieren, wie die Daten von dem Prozessor verar- 
beitet werden. Sobald die Daten fiber den Interface-Code an ei- 
ne (Oder mehrere) VPa ubergeben werden, ist ein Debugger fur 
VPUs zu aktivieren. Wird der Code zuriick an den PROZESSOR ge- 
sendet, soil wiederum der PROZESSOR-Debugger aktiviert werden. 
Es ist dsQier also mdglich und bevorzugt, derartige Abl&ufe 
durch das Einffigen von Steuercodes fAr Debugger imd/oder Bnt- 
wicklungssysteme in den Interface-Code abzuwickeln. 

Die Kornmunikation und Steuerung zwischen den unterschiedlichen 
Entwicklxingssystemen soil daher bevorzugt mittels in die In- 
terface-Codes von PROZESSOR und/oder VPU eingebrachte Steuer- 
codes abgewlckelt werden. Die Steuercodes kdnnen dabei beste- 
henden Standards fiir die Steuerung ' von Entwicklimgssystjemen 
weitgehend entsprechen. 

Die Verwaltung und Koramunikation der Entwicklungssysteme wird 
vorzugsweise wie beschrieben in die Interface-Codes abgewik- 
kelt, .kann jedoch - sofem sinnvoll - auch getrennt von die- 
sen, nach einem entsprechenden ahnlichen Verfahren abgewickelt 
werden . 



In vielen Programmiersprachen, besonders in sequentiellen wie 
z. B, C, wird eine.exakte zeitliche Reihenfolge implizit durch 
die Sprache vorgegeben. Bei sequentiellen Programmiersprachen 
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geschieht dies beispielsweise durch die Reihenfolge der ein- 
zelnen Anweisungen. Sofem durch Programmiersprache iind/oder 
den Algorithmus erforderlich, lafit sich die Zeit information 
auf Synchronisationsmodelle wie RDY/ACK und/oder REQ/ACK oder 
ein Time-Stamp-Verfahren abbilden. * 

Beispielsweise wird eine nachfolgende for-Schleife nur dann 
durchlaufen und iteriert, wenn eine Variable, hier input stream 
je Durchlauf mit einem RDY quittiert ist. Bleibt RDY aus, wird 
der Schleifendurchlauf bis zura Eintreffen RDY angehalten: 

while TRUE- 
S := 0 

for i: 1 to 3 

s s -¥ inputstream; 

Die Eigenschaft der sequentiellen Sprachen, nur von der Be- 
fehlsverarbeitung gesteuert zu werden, wird mit dem Datenflufi- 
prinzip die Verarbeitung durch den Datenstrom, bzw. die Exi- 
st enz von Da ten zu steuem verbunden. Mit anderen Wort en wird 
ein Befehl und/oder eine Anweisung (z. B. s s + 
inputstream;) nur verarbeitet, wenn die Operation ausgefuhrt 
werden kann und die Daten verfugbar sind. 

Bemerkenswert ist, daS dieses Verfahren gewohnlicherweise zu 
keiner Andening der Syntax oder Semantik einer Hochsprache 
ftort. 

Komplexere Punktionen einer Hochsprache, wie z. B. Schleifen, 
werden durch Makros realisiert. Die Makros werden vom Compiler 
vorgegeben und zur fibersetzungszeit instantiiert . 
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Die Makros sind entweder aus einfachen Sprachkonstrukten der 
Hochsprache oder auf Assemblerlevel aufgebaut. Makros k6nnen 
parametriert sein, um eine einfach Adaption an den beschriebe- 
nen Algorithmus zu ermoglichen. (vgl. auch PACTll) 



Ein Standardprozessor z.B. ein RISC, CISC, DSP (CPU) wird also 
mit einem rekonf igurierbaren Prozessor (VPU) gekoppelt. 

Zwei unterschiedliche, bevorzugt jedoch auch zugleich imple- 
ment ierbare Kopplungsvaricuiten konenn wie folgt beschrieben 
sein. 

Eine erste Variante sieht eine direkte Ankoppelung an den Be- 
fehlssatz einer CPU vor (Befehlssatzkopplimg) . 
Eine zweite Varisuite sieht eine Ankoppelxing {iber Tabellen im 
Hauptspeicher vor. Es sind also Tabellenmittel vorgesehen. 

Innerhalb eines Instniktionssatzes (ISA) einer CPU sind fur 
gevdhnlich freie unbenutzte Befehle vorhanden. Einer oder eine 
Mehrzahl dieser f reien unbenutzen Befehle wird nunmehr f\ir die 
Steuerung von VPUs verwendet (VPUCODE) . 

Durch die Dekodiertmg eines VPUCODEs* wird eine Konfigurations- 
einheit (CT) einer VPU angesteuert die in AbhSngigkeit des 
VPUCODEs bestimmte. AblSufe ausffihrt. Es ist also eine zur VPU- 
Decodierung ansprechbare CT vorhanden. 

Beispielsweise kann ein VPUCODE das Laden und/oder Ausflihren 
von Konfigurationen durch die Konfigurationseinheit (CT) fdr 
eine VPU auslosen. 
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In einer erweiterten Ausfiihrung kann ein VPUCODE xiber eine 
Ubersetzungstabelle, die bevorzugt von der CPU, alternativ 
aber auch von der oder einer VPU oder einer extemen Einheit 
aus verwaltet wird, auf unterschiedliche VPU-Kommandos liber- 
setzt werden 

Die Konfigurationstabelle kann in Abhangigkeit von dem ausge- 
fuhrten CPU Programra oder Codeabschnitt gesetzt werden. 

Die VPU ladt nach Eintreffen eines Ladekommandos Konf iguratio- 
nen aus einera eigenen oder mit der CPU geteilten Speicher. 
Insbesondere kann eine VPU-Konf iguration im Code des aktuell 
ausgefOhrten CPU- Programmes beinhaltet sein. 

Nach Erhalt eines Ausfahrungskoramandos fiihrt eine VPU die aus- 
zuf^ihrende Konf iguration aus und die entsprechende Datenverar- 
beitung durch. Das Beenden der Datenverarbeitung kann durch 
ein Terminierungssignal (TERM) an die CPU angezeigt werden* 
Dazu sind entsprechende Signal lei tungen/Interrupt-Bingange 
usw. vorhanden und/oder; ausgebildet. 

Das Auftreten eines VPUCODEs kdnnen solange Wartezyklen auf 
der CPU ausgefOhrt werden, bis das Terminierungssignal (TERM) 
der Beendigimg- der Datenverarbeitung von der VPU eintrif f t . 

In einer bevorzugtien Ausgestaltung wird mit der Verarbeitung 
der nSchsten Codes f ortgef ahren . Tritt ein weiterer VPUCODE 
auf, kaim sodaxm auf die Beendigung des vorhergehenden gewar- 
tet werden, oder sSmtliche geatartete VPUCODEs werden in einer 
Verarbeitungspipeline eingereiht, oder ein Taskwechsel wird 
insbesondere wie nachfolgend beschrieben ausgefilhrt. 
Die Beendigung einer Datenverarbeitung wird .durch das Eintref- 
fen des Terminierungssignal (TERM) in einem Statusregister si- 
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gnalisiert. Die Terminierungssignale treffen in der Reihenfol- 
ge einer nraglichen Verarbeitungspipeline ein. 



Die Datenverarbeitimg auf der CPU kann durch das Testen des 
Statusregisters auf das Eintreffen elnes Terminierungssignales 
synchronisiert werden. 

In einer moglichen Ausgestaltung kann, sofem. eine Applikation 
vor decn Eintreffen von TERM z.B. durch Datenabhangigkeiten 
nicht fortgesetzt werden kann, ein Taskwechsel ausgelost wer- 
den. 

Es ist bevorzugt, wenn lose Kopplxmgen zwischen. Prozessoren 
und VPUs aufgebaut sind, bei welchen VPUs weitestgehend als 
unabhSngige Coprozessoren arbeiten. 

Eine derartige Kopplung sieht eine oder mehrere gemeinsame Da~ 
tenquellen iind -senken, zumeist Qber gemeinsame Bussysteme 
und/oder gemeinsame Speicher vor. Uber DMAs und/oder andere 
Speicherzugriffskontroller werden Daten zwischen einer CPU und 
einer VPU ausgetauscht . Die Synclironisation der Datenverarbei- 
tung erfolsrt bevorzugt taber eine Interyuptsteuerung oder einen 
Statusabfragemechanismus (z-.B. Polling). 

Eine enge Ankopplung entspricht der vorab beschriebenen direk- 
ten Ankopplung einer VPU in den Befehlssatz einer CPU. 

Bei einer direkten Rechenwerk -Ankopplung ist besonders auf ei- 
ne hohe Rekonf igurationsperformance zu achten. Bevorzugt kann 
daher die Wave- Rekonf igur at ion zum Einsatz komraen. Desweiteren 
werden die Konfigurat ions wort e bevorzugt vorab derart vorgela- 

den, dass bei Ausfiihrung des Befehls die Konf iguration beson- 
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ders schnell (mittels Wave -Reconfiguration im Optimalfall in- 
nerhalb eines Taktes) konfiguriert warden kann. Im ubrigen wa- 
re auch tnoglich, anstelle einer Array-Teilkonf iguration bei 
hoch performanten, insbeeondere aber auch bei ilberwiegend nie- 
derperformanten Anwendungen mehrere insbesondere identische 
Arrays vorzusehen, von diesen wenigstens eines fur eine neue 
Task umzukonfigurieren, insbesondere im Vorgriff , und dann 
nach Bedarf anstelle einer Umkonf iguration oder Teilumkonf igu- 
ration eines integralen multidimensionalen partiell zur Lauf- 
zeit rekonf igurierbaren grobgranularen Feldes einfach auf ein 
anderes Array vollst^dig zu wechseln. Signale konnen dabei z. 
B. uber MUX-/Dem\ixstufen den Teilarrays zugefuhrt werden, ins- 
besondere I/O-, Daten-, Status- und/bder Triggersignale . 

Fur die Wave -Reconfiguration werden bevorzugt die voraussicht- 
lich auszufuhrenden Konf igurationen vorab durch den Compiler 
z\xr Corapilezeit erkannt und zur Laufzeit entsprechend vorgela- 
den. 

Zum Zeitpunkt der Be£ehlsau8fQhrung wird die entsprechende 
Konf iguration gegebenenfalls fttr jede PAE einzeln und/oder filr 
eine PAE-Teilmenge einzeln selektiert und ausgefOhrt. Auch 
derartige Verfahren sind nach den e.g. Schriften bekaimt. 

Eine bevorzugte Implementierung kann unterschiedliche Daten- 
transfers zvischen einer CPU und VPU yorsehen^ Drei besonders 
bevorzugte einzeln oder kombiniert einsetzbare Methoden werden 
nachfolgend beschrieben. 

Bei einer Registerkopplung kann die VPU Daten aus einem CPU- 
Register entnehmen, verarbeiten und in ein CPU-Register zu- 
rfickschreiben. 
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Bevorzugt werden Synchronisationsmechanismen zwischen der CPU 
und der VPU eingesetzt. 



Beispielsweise kann die VPU durch das Binschreiben der Daten 
in ein CPU-Register durch die CPU ein RDY-Signal erhalten und 
daraufhin die eingeschriebenen Daten verarbeiten. Das Auslesen 
von Daten aus einem CPU-Register durch die CPU kann ein ACK* 
Signal generieren, wodurch die Datenabnahme durch die CPU der 
VPU signalisiert wird. Die Verwendung des per se bekaimten 
RDY/ACK-Protokolls in unterschiedlicher Auspr§gung ist vorlie- 
gend gerade bei grobgranularen Zellen der rekonfigurierbaren 
Einheiten vorteilhaft. 

CPUs stellen typischerweise keine entsprechenden Mechanismen 
2ur Verfugung. 

Zwei m6gliche Ldsungen werden naher beschrieben: 

Ein einfach zu realsierenden Ansatz ist, die Datensynchronisa- 
tion uber ein Statusregister durchzufuhren. Beispielsweise 
kann die VPU das erfolgte Auslesen von Daten aus einem Regi- 
ster und das damit verbundene ACK-Signal und/oder das Ein- 
schreiben. von Daten in ein Register und das damit verbundene 
RDY-Signal in dem Statusregister anzeigen. Die CPU testet zu- 
nSchst das Statusregister und fOhrt beispielsweise so lange 
Warteschleifen oder Taskwechsel aus, bis - je nach Operation - 
das RDY Oder ACK eintraf . Danach fuhrt die CPU den jeweiligen 
Registerdatentransfer aus. 

In einer erweiterten Ausgestaltxing wird der Befehlssatz der. 

CPU um load/store- Instmktionen mit integrierter Statusabfrage 

(load_rdy, store_ack) erweitert. Beispielsweise. wird bei einem 

store_ack nur dann ein neues Datenwort in ein CPU-Register ge- 
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schrieben, wenn das Register vorher von der VPU ausgelesen 
wurde und ein ACK eintraf . Entsprechend liest load_rdy nur Da- 
ten aus einem CPU-Register, wenn die VPU vorher neue Daten 
eingeschrieben und ein RDY generiert hat* 

Daten, die zu einer auszufuhrenden Konf iguration gehdren kdn- 
nen sukzessive, quasi durch Block-Moves Shnlich wie nach dem 
Stand der Technik in die CPU-Register geschrieben und/oder aus 
diesen gelesen warden. Ggf . implementierte Block-Move- 
Instruktionen kdnnen bevorzugt durch die beschriebene inte- 
grierte RDY/ACK Statusabfrage erweitert werden. 

Es ist offensichtlich, dass eine Vielzahl von ieichten Modifi* 
kationen und unterschiedlichen Ausgestaltungen dieses Grund* 
verfahrens m6glich sind. 

Die bereits erw^hnte Wave -Rekonf iguration erlaubt das Starten 
eines neuen VPU-Befehls und der entsprechenden Konf iguration, 
sobald die Operanden des vorhergehenden VPU-Befehls aus den 
CPU-Registem abgenoramen wurden. Die Operanden fur den neuen 
Befehl konnen direkt nach Befehlsstart in die CPU- Register ge- 
schrieben werden. 

Entsprechend des Wave -Rekonf iguration- Verfahrens wird die VPU 
successive mit Fertigstellung der Datenverarbeitung des vorhe- 
rigen VPU-Befehls fftr den neuen VPU-Bef ehl umkonf iguriert imd 
die neuen Operanden verarbeitet. 

Weiterhin konnen Daten zwischen einer VPU tmd einer CPU durch 
geeignete Buszugriffe auf gemeinsame Ressourcen ausgetauscht 
werden. 
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Sofern Daten ausgetauscht werden sollen, die kurz zuvor von 
der CPU verarbeitet wurden und daher voraussichtlich noch im 
bevorzugt vorzusehenden Cache der CPU liegen bzw. sofort an- 
schliessend von der CPU verarbeitet werden und daher sinnvol- 
lerweise in den Cache der CPU gelegt werden, werden diese be- 
vorzugt von der VPU aus dem Cache der CPU gelesen, bzw. in den 
Cache der CPU geschrieben. Dies kann durch geeignete Analysen 
weitestgehend vorab zur Compilezeit der Applikation durch den 
Compiler festgestellt und der Binarcode entsprechend generiert 
werden » 

Sofern Daten ausgetauscht werden sollen, die sich voraussicht- 
lich nicht im Cache der CPU befinden bzw. voraussichtlich 
nicht nachfolgend im Cache der CPU ben6tigt werden, werden 
diese bevorzugt von der VPU direkt vom extemen Bus und der 
damit verbiandenen Datenquelle (z.B. Speicher, Peripherie) ge- 
lesen, bzw. an den extemen Bus und der damit verbiindenen Da- 
tensenke (z.B. Speicher, Peripherie) geschrieben. Dies kann 
durch geeignete Analysen weitestgehend vorab zur Con^ilezeit 
der Applikation durch den Compiler festgestellt und der Binar- 
code entsprechend generiert werden. 

Bei. .einem Transfer liber den Bus am Cache vorbei wird bevorzugt 
ein Protokoll zwischen Cache und Bus impleraentiert, das fQr 
einen korrekten Inhalt des Caches sorgt. Beispielsweise kann 
das bekannte MBSI -Protokoll nach dem Stand der Technik hierzu- 
verwendet werden. 

Die beschriebenen Verfahren mClssen zun^chst keinen besonderen 
Mechanismus fiir die Unterstutzung von Betriebssystemen vorse- 
hen. Es ist nSmlich bevorzugt, sicherzustellen, dass ein aus- 
zufilhrendes Betriebssystem sich entsprechend des Status einer 
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zu unterstutzenden VPU verhSlt, was moglich ist und wozu ins- 
besondere Scheduler vorgesehen sein k6nnen. 



Bei einer engen Rechenwerkkopplung wird bevorzugt das Status- 
register der CPU abgefragt, in welches die angekoppelte VPU 
ihren Datenverarbeitungsstatus (Terminierungssignal) eintragt. 
Soil eine weitere Datenverarbeitung an die VPU ubertragen wer- 
den, und die VPU hat die vorherige Datenverarbeitung noch 
nicht beendet wird gewartet und/oder bevorzugt ein Taskwechsel 
ausgef ahrt . 

PGr eine Coprozessorkopplung werden bevorzugt uber das Be- 
triebssystem, i.b, den Scheduler gesteuerte Mechanismen ver- 
wendet : 

Ein einfacher Scheduler kann nach Obertragung einer Funktion 
auf eine VPU entweder den aktuellen Task auf der CPU weiter- 
laufen lassen/ sofern dieser unabhangig und parallel zur Da- 
tenverarbeitung auf einer VPU ablaufen kann. Sofern oder so- 
bald der Task auf die Beendigung der Datenverarbeitung auf der 
VPU warten muss, schaltet der Taskscheduler auf einen anderen 
Task um. 

Jeder neu aktivierte Task wird, sofern er die VPU verwendet, 
vor Verwendung prufen, ob diese fQr eine Datenverarbeitung zur 
Verfixgung steht und/oder aktuell noch Daten verarbeitet; dann 
soil entweder auf die Beendigxing der Datenverarbeitung gewar- 
tet Oder bevorzugt der Task gewechselt werden. 

Ein einfaches und dennoch leistungsfShiges Verfahren kann 
durch sogenannte Descriptor Tables aufgebaut werden, die be- 
spielswexse folgendermafien realisiert werden k6nnen: 
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Jeder Task generiert zum Aufruf der VPU eine Oder mehrere Ta- 
belle(n) (VPUCALL) mit einem geeigneten festgelegten Datenfor- 
mat in dem ihm zugewiesenen Speicherbereich. Diese Tabelle be- 
einhaltet saratliche Steuerinformation fur eine VPtJ, wie z.B. 
das auszufiihrende Programra / die auszufvihrende Konfiguration 
und/oder Zeiger auf die Speicherstelle <n) oder Datenquellen 
der Eingangsdaten und/oder die Speicherstelle (n) oder Daten- 
senken der Brgebnisdaten und/oder weitere Ausf^lhrungsparame- 
ter, z.B. DatenarraygroSen. 

Im Speicherbereich des Betriebssystems befindet sich eine Ta- 
belle Oder verkettete Liste (LINKLIST) , die auf samtliche 
VPUCALL-Tabellen in der Reihenfolge ihrer Brstellung zeigt. 

Die Datenverarbeitung auf der VPU ISuft nunmehr derart ab, 
dass ein Task einen VPUCALL erstellt und uber das Betriebssy- 
etem die VPU aufruft. Das Betriebssystem erstellt einen Ein- 
trag in der LINKLIST. Die VPU arbeitet die LINKLIST ab und 
fuhrt die jeweils ref erenzierten VPUCALL aus. Die Beendigung- 
einer der jeweiligen Datenabarbeitung wird jeweils durch einen 
entsprechenden Eintrag in die LINKLIST \ind/oder VPUCALL Tabel- 
le ange zeigt. 

Die VPU arbeitet somit weitgehend unabhangig von der CPU. Das 
Betriebssystem und/oder die jeweiligen Task massen lediglich 
die Tabellen (LINKLIST bzw. VPUCALL) Qberwachen. 

Besonders performanceef f izient arbeiten die beiden Verfahren, 
wenn als VPU eine Architektur zum Einsatz kommt, die eine mit • 
der Datenverarbeitung Oberlagerte und/oder liberlagerbare Re- 
konfiguration zulSsst. 
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Damit ist es moglich, eine neue Datenverarbeitung und eine 
ggf . damit verbundene Rekonf iguration sofort nach Lesen der 
letzten Operanden aus den Datenquellen zu starten, Mit anderen 
Worten ist fiir die Synchronisation nicht mehr das Beenden der 
Datenverarbeitung, sondem das Lesen der letzten Operanden er- 
forderlich. Dadurch wird die Performance der Datenverarbeitung 
erheblich gesteigert. 

inen zusatzlichen Einfluft auf die Betrachtung und den Umgang 
mit Zustanden hat der m5gliche Einsatz eines Betriebssystemes. 
Betriebssysteme verwenden beispielsweise TasJc-Scheduler zum 
Verwalten mehrere Aufgaben (Tasks), urn ein Multitasking zur 
Verfiigung zu stellen. 

Task-Scheduler brechen Tasks zu einem bestinnnten Zeitpunkt ab, 
starten andere Tasks und kehren nach der en Abarbeitung zur 
Weiterbearbeitung des abgebrochenen Tasks zurUck. 
Sofern sichergestellt ist, dafi eine Konfiguration - die der 
Abarbeitung eines Tasks entspricht - nur nach der kompletten 
Abarbeitung - d.h. wenn alle innerhalb dieses Konfigurations- 
zyklusses zu bearbeitende Daten und Zustande gespeichert sind 
- terminiert, kannen lokal relevante ZustMnde ungespeichert 
bleiben. 

Sofern der Task-Scheduler allerdings Konfigurationen vor deren 
vollstandiger Abarbeitung abbricht, mUssen lokale Zustande 
und/oder Daten gespeichert werden. Weiterhin ist dies von Vor- 
teil, wenn die Abarbeitungszeit einer Konfiguration nicht vor- 
hergesagt werden kann. In Verbindung mit dem bekannten Halte- 
problem und dem Risiko,. daB eine Konfiguration (z.B. durch ei- 
nen Fehler) gar nicht terminiesrt, erscheint dies weiterhin 
sinnvoll, um damit einen Deadlock des gesamten Systems zu ver- 
hindern. 

Mit anderen Worten sind, unter Berticksichtung von Taskwech- 
seln, relevante Zustande auch als solche anzusehen, die far 
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einen Taskwechsel und ein erneutes korrekes Aufsetzen der Da- 
tenverarbeitung notwendig sind. 

Bei einem Taskswitch ist somit der Speicher far Ergebnisse und 
ggf • auch der Speicher fiir die Operanden zu sichern und zu ei- 
nem spateren Zeitpunkt, also bei der RUckkehr zu diesem Task, 
wieder herzustellen. Dies kann vergleichbar zu den PUSH/POP 
Befehlen und Verfahren nach dem Stand der Technik erfolgen. 
Weiterhin ist der Zustand der Datenverarbeitung zu sichern, 
also der Zeiger auf die zuletzt vollstSndig bearbeiteten Ope- 
randen. Es sei hier besonders auf PACT18 verwiesen. 

Abhangig von der Optimierung des Taskswitches gibt es bei- 
spielsweise zwei MSglichkeiten: 

a) Die abgebrochene Konfiguration wird neu konfiguriert und 
nur die Operanden werden geladen. Die Datenverarbeitung be- 
ginnt von neuem, als ob die Bearbeutung der Konfiguration noch 
gar nicht begonnen v/urde. Mit anderen Wort en werden einfach 
alle Datenberechnungen von vome an ausgeftihrt, wobei ggf . Be- 
rechnungen bereits zuvor durchgefiihrt wurden. Diese Moglich- 
keit ist einfach aber nicht sehr effizient. 

b) Die abgebrochene Konfiguration wird neu konfiguriert, wobei 
die Operaden und bereits berechneten Ergebnisse in die jewei- 
ligen Speicher geladen werden. Die Datenverarbeitung wird bei 
den Operanden. fortgesetzt die nicht mehr voUstandig berechriet 
wurden. Dieses Verfahren ist sehr viel effizienter, setzt aber 
voraus, dafi ggf. zusatzliche ZustSnde die wahrend der Verar- 
beitung der Konfiguration entstehen relevant werden, bei- 
spielsweise muB zumindest ein Zeiger auf die zuletzt vollstSn- 
dig verechneten Operanden gesichert werden, damit bei deren 
Nachfolgern nach erfolgter neuer Konfiguration neu aufgesetzt 
werden kann. 

Eine besonders bevorzugte Variante zur Verwaltung von relevan- 

ten Daten wird durch den nachfolgend beschriebenen Kontext 

Switch zur Verfiigung gestellt. Bei Task-Wechseln und/oder bei 
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der Ausfiihrung von Konfigurationen und derem Wechsel (siehe 
beispielsweise Patentanmeldung PACT15, die zu Of fenbarungs- 
zwecken vollumfSnglich eingegliedert ist) kann es erforderlich 
sein, Daten Oder Zustande, die typischerweise nicht zusairanen 
mit den Arbeitsdaten in die Speicher abgelegt werden, da sie 
beispielsweise lediglich einen Endwert markieren, fur eine 
nachfolgende Konfiguration zusichern. 

Der erfindungsgemSBe Kontext Switch wird der art durchgefahrt^ 
dass eine erste Konfiguration entfemt wird, die zu sichernden 
Daten verbleiben in den entsprechenden Speichern (REG) (Spei- 
cher, Register, ZShler, etc) . 

Eine zweite Konfiguration wird geladen, diese verbindet die 
REG in geeigneter Weise und definierter Reihenfolge mit einem 
Oder mehreren globalen Speicher (n) . 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf den/die globalen Speicher zuzugreifen. 
Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf als Speicher ausgestaltete REG zuzugreifen. 
Entsprechend der konf igurierten Verbindung zwischen den REG 
werden die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jeweiligen Adres- 
sen von Adressgeneratoren vorgegeben werden. Der Adressgenera- 
tor generiert die Adressen far den/die globalen Speicher (n) 
derart, dass die beschriebenen Speicherbereiche (PUSHAREA) der 
entfernten ersten Konfiguration eindeutig zugeordnet werden 
kdnnen. 

Mit anderen Worten, es sind bevorzugt far unterschiedliche 
Konfigurationen uiiterschiedliche AdressenrSume vorgesehen. Die 
Konfiguration entspricht einem PUSH gewdhnlicher Prozessoren. 

Danach verwenden andere Konfigurationen die Ressourcen. 

Die erste Konfiguration soil wieder gestartet werden. Zuvor 

wird eine dritte Konfiguration gestartet, die die REG der er- 
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sten Konfiguration in einer definierten Reihenfolge miteinan- 
der verbindet. 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf den/die globalen Speicher zuzugreifen. 

Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf als Speicher ausgestaltete REG zuzugreifen. 

Ein Adressgenerator generiert Adressen derart, dass ein kor- 
rekter Zugrif f auf die der ersten Konfiguration zugeordnete 
PUSH7VREA erfolgt. Die generierten Adressen und die konfigu- 
rierte Reihenfolge der REG sind derart, dass die Daten der REG 
in der ursprtlnglichen Ordnung aus den Speichern in die REG ge- 
schrieben werden. Die Konfiguration entspricht einezn POP ge- 
w5hnlicher Prozessoren. 

Die erste Konfiguration wird wieder gestartet. 

Zusannaengefafit wird ein Kontext Switch derart durchgeftihrt^ 
dass durch das Laden besonderer Konfigurationen, die ahnlich 
von POSH/POP bekannter Prozessorarchitekturen atbeiten, die zu 
sichernden Daten mit einem globalen Speicher ausgetauschen 
werden. 

Die Funktion soil in einem Beispiel verdeutlicht werden: 

Eine Funktion addiert 2 Zahlenreihen, die LSnge der Reihen ist 

zur Obersetzungszeit nicht bekannt, sondern erst zur Laufzeit. 

proc example 

while i<length do 
x[i] - a[i] + b[i] 

Die Funktion wird nun wahrend ihrer Ausfiihrung unterbrochen, 

beispielsweise durch einen Task-Switch oder well der fiir x 
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vorgesehene Speicher voll ist. a,b,x befinden sich zu diesem 
Zeitpunkt erfindungsgemaB in Speichern. i und ggf . length mOs- 
sen jedoch gesichert warden. 

Dazu wird die Konfiguration example terminiert, wobei die Re- 
gisterinhalte erhalten bleiben und eine Konfiguration push ge- 
startetr die i und length aus den Registern liest und in einen 
Speicher schreibt. 

proc push 

merat<push_adr_example>] = i 
push_adr_example++ 
nieni[<push_adr__exaniple>J = length 

Nach der AusfQhrung wird push terminiert und die Registerin- 
halte kannen gel5scht werden. 

Andere Konfigurationen werden ausgefOhrt. Nach einiger Zeit 
wird die Konfiguration example wieder gestartet. 
Zuvor wird eine Konfiguration pop gestartet, die die Registe- 
rinhalte wieder aus dem Speicher liest. 

proc pop 

i = inemt<push_adr_exainple>] 

pushjadr_example++ 

length « meia[<push_adr_example>] 

Nach der AusfQhrung wird pop terminiert und die Registerinhal- 
te bleiben bestehen* Die Konfiguration exan^le wird wieder ge- 
startet 

Beschreibung der Figuren 

Figur 1 verdeutlicht ein Beispiel das vorgeschlagene Verfahren 
und zeigt einen mdglichen Sy stemaufbau . Dabei ist ein PROZES* 
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SOR (OlOl) uber ein geeignetes Interface (01O2) zum Daten- und 
Status -austausch mit einer VPU (0103) verbunden. 
Ein PROGRAMM-Code (0110) wird (2. B. durch einen Praprozessor 
fur einen Compiler) beispielsweiae gemaS den beschriebenen Ex- 
traktionsmethoden in einen fiir den PROZESSOR geeigneten Teil 
(0111) und einen VPU-geeigneten Teil (0112) zerlegt. 

0111 wird durch einen dem PROGRAMM-Code entsprechenden Stan- 
dard Compiler (0113) iibersetzt, wobei zuvor der zusatzliche 
Code zur Beschreibung und Vervaltung des Interfaces (0102) 
zwischen dem PROZESSOR und einer VPU aus einer Datenbank 
(0114) eingefugt wird, Auf 0101 ausfuhrbarer sequentieller 
Code wird generiert (0116) und sofern notwendig die entspre- 
chende Programmierung (0117) dea Interfaces (0102) . 

Der Standard -Compiler kann dergestalt sein, da& or als 
marktiibliches W^rkzeug oder im Rahraen einer marktCiblichen Ent- 
wicklungsumgebung vorliegt. Der Praprozessor xmd/oder mogli- 
cherweise der VPU-Compiler und/oder m&glicherweise der Debug- 
ger und weitere Werkzeuge k6zmen beispielsweiae in eine beste- 
hende markt^liche Entwicklungsumgebung Integriert werden. 

0112 wird durch einen VPU Compiler (0115) iU^ersetzt, wobei zu- 
sitzlicher Code zur Beschreibung und Veirwaltvmg des Interfaces 
(0102) aus einer Datenbank (0114) eingefugt wird. Auf 0103 
ausfulirbare Konfigurationen werden generiert (0118) und sofern 
notwendig die entsprechende Programmierung (0119) des Interfa- 
ces (0102) . Es soli ausdriicklich erwihnt werden, daS prinzipi- 
ell auch Compiler nach DE 101 39 170,6 fdr 0115 verwendet wer- 
den k6nnen. 

In Figur 2 ist beispielhaf t ein prinzipieller Ablauf einer 
Compilation dargestellt. Ein PROC^RAMM (0201) wird in der Ex- 
traktionseinheit (0202) nach unterschiedlichen Verfahren in 
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VPU- Code (0203) und PROZESSOR-Code (0204) zerlegt. Unterschied- 
liche Methoden konnen in beliebiger Kombination zur Extraktion 
angewendet werden, beispielsweise Hinweise im urspriinglichen 
PROGRAMM (0205) und/oder Unterprogrammauf rufe (0206) vind/oder 
Analyseverfahren (0207) und/oder sine Verwertung von objekt- 
orientierten Klassenbibliotheken (0206a), Der jeweils extra- 
hierte Code wird ggf . (ibersetzt und ggf . auf seine Eignung fur 
das jeweilige Zielsystem bin viberpruft (0208) . Dabei ist eine 
Rilckkopplung (02a9) auf die Extraktion mdglich, um Verbesse- 
rungen durch eine geSnderte Zuordnung der Codes zu einem PRO- 
ZESSOR Oder einer VPU bzw. einer Vielzahl derselben zu erhal- 
ten. 

Danach (0211) wird 0203 durch den Interface -Code aus einer Da- 
tenbank (0210) erweitert (0212) und/oder 0204 wird durch den 
Interface -Code aus 0210 zu 0213 erweitert. 
Der entstcuidene Code wird auf seine Performance analysiert 
(0214), ggf. ist eine Rilckkopplung (0215) auf die Extraktion 
moglich, um Verbesserungen durch eine geanderte Zuordnung der 
Codes zum PROZESSOR Oder einer VPU zu erhalten. 
Der entstandene VPU-Code (0216) wird fQr eine weitere Uberset- 
zung an einen nachgeschalteten fur die VPU geeigneten Compiler 
weitergegeben. Der entstandene PROZESSOR-Code (0217) wird fQr 
die weitere Ubersetzung in einem beliebigen nachgeschalteten 
fttr den PROZESSOR geeigneten Compiler weiterverarbeitet - 

Bs soli angemerkt werden, dafi' einzelne Schritte je nach Ver- 
fahren ausgelassen werden konnen. Wesentlich ist, da£ ein zu- 
mindest weitgehend kompletter und ohne, wenigstens ohne signi- 
fikanten Eingriff durch den Programmierer direkt tibersetzbarer 
Code an jeweils nachgeschaltete Compilersysteme ausgegeben 
wird. 
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Es wird deninach vorgeschlagen, daJS ein PrSprozessormittel mit 
einem Codeeingang fiir die Einspeisung von zu compilierendem 
Code, mit Codeanalysemitteln, insbesondere Codestruktur 
und/oder Datenformat- und/oder Datenstroms-Erkennungs- 
und/oder Bewertungsmitteln sowie mit einem Auf teilungsbewer- 
tungsmittel zur Bewertung einer im Ansprechen auf Signale aus 
dem Codeanalysemittel vorgenommenen Codeaufteilung sowie gege- 
benenfalls einem Iterationsmittel zur Wiederholung einer Code- 
aufteilung bis 2um Erreichen stabiler und/oder hinreichend ak- 
zeptabler Werte mit zumindest zwei Teilcodeausgangen versehen 
ist, wobei ein erster Teilcodeausgang Teilcode fur zumindest 
einen herkdramlichen Prozessor ausgibt, und wenigstens ein wei- 
terer Teilcodeausgang zur Abarbeitung mit rekonf igurierbaren 
Logikeinheiten, insbesondere mehr- bzw. multidimensionale ins- 
besondere Zellstrukturen aufweisend, insbesondere grobgranula* 
re datenverarbeitende und/oder Logikzellen (PAEs) mit Rechen- 
werken und dergleichen sowie ggf * zugeordneten Registermitteln 
und/oder feingranularen Steuer- und/oder Kontrollmitteln wie 
ZustandsmaschineUf RDY/ACK-Trigger- und Kommunikationsleitiin- 
gen usw bestimmten Code ausgibt. Beide Teilcodeausg&nge kdnnen 
in multiplexweise seriell auf einem physikalischen Ausgang 
liegen* 

Die Datenbank fur die Interface-Codes (0210) wird unabMngig 
und vor dem Compilerdurchlauf aufgebaut. Beispielsweise sind 
folgende Quellen fQr die Datenbank moglich: Vom Liefereuiten 
vorgegeben (0220), vom Benutzer programmiert (0221) oder auto- 
matisch von einem Entwicklungssystem generiert (0222). 

Der Aufbau einer besonders bevorzugten VPU ist in Figur 3 dar- 
gestellt:. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (0301) steuem und verwalten eine Anordnung von rekon- 
f igurierbaren Elementen (PACs) (0302). Den CT's ist ein. loka- 
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ler Speicher fur die Konfigurationen zugeordnet (0303) . Der 
Speicher verfiigt weiterhin tiher ein Interface (0304) zu einem 
globalen Speicher, der die Konf igurationsdaten zur Verfilgung 
stellt. Uber ein Interface (0305) sind die Konf igurationsab- 
ISuft steuerbar. Ein Interface der rekonf igurierbaren Elemente 
(0302) zur Ablaufsteuerung und Ereignisverwaltung (0306) ist 
vorhanden, ebenso ein Interface zum Datenaustausch (0307). 

Pigur 4 zeigt einen Ausschnitt aus einem beispielhaften CPU 
System, beispielsweise einem DSP des Types C6000 von Texas In- 
struments (0401) . Dargestellt sind Programmspeicher (0402) , 
Datenspeicher (0403) , beliebige Peripherie (0404) und EMIP " 
(0405) . Uber einen Speicherbus (0406) und einem Peripheriebus 
(0407) ist eine VPU als Coprozessor integriert (0408) . Ein 
DMA-Kontroller (EDMA) (0409) kann beliebige DMA- Transfers, 
beispielsweise zwischen Speicher (0403) und VPU (0408) Oder 
Speicher (0403) \xnd Peripherie (0404) durchftihren. 

Figur 5 zeigt eine abstraktere Systemdefinition. Einer CPU 
(0501) ist Speicher (0502) zugeordnet auf den diese schreiben- 
den und/oder lesenden Zugriff besitzt. Eine VPU (0503) ist mit 
dem Speicher gekoppelt. Die VPU ist in einen CT-Teil (0509) 
und die rekonfigurierbaren Elemente zur Datenverarbeitung 
(0510) ttntergliedert. 

Zur Steigerung der Speicherzugrif f e kann der Speicher mehrere 
unabhangige Zugriffsbusse aufweisen (raultiport) . In einer be- 
Bonders bevorzugten Ausgestaltxing ist der Speicher in mehrere 
unabhangige Segmente (Speicherbcuiks) segmentiert, wobei auf 
jede Bank unabhSngig zugriffen werden kann. Samtliche Segmente 
liegen vorzugsweise ixmerhalb eines einheitlichen Adressraums. 
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Vorzugsweise steht ein Segment hauptsachlich fiir die CPU zur 
Verfiiigung (0504), ein weiteres Segment steht hauptsachlich fur 
die Datenverarbeitung der VPU zur VerfOgung (0505), ein weite- 
res Segment steht hauptsachlich fQr die Konf igurationsdaten 
der VPU zur Verfiigung (0506) . 

Typischerweise und bevorzugt weist eine vollausgestaltete VPU 
eigene Adressgeneratoren und/oder DMAs auf urn Datentransfers 
durchzuf olhren . Alternativ und/oder zus4tzlich ist es mSglich, 
dass ein DMA (0507) innerhalb des Systems (Fig. 5) fHx Daten- 
transfers mit der VP0 vorgesehen ist. 

Das System enthalt 10 (0508) auf die CPU und VPU Zugrif f haben 
konnen. 

Sowohl CPU als auch VPU konnen jeweils dedizierte Speicherbe- 
reiche und lO-Bereiche aufweis.en, auf die der jeweils andere 
keinen Zugrif f hat. 

Ein Datensatz (0511) der im Speicherbereich und/oder im 10- 
Bereich und/oder partiell in einem von beiden liegen kann wird 
zur Kommunikation zwischen CPU und VPU verwendet, z.B. zum 
Austausch von Basisparametem und Steuerlnformatlon. Der Oa- 
tjensatz kann beispielsweise folgende Information beeinhalten: 

1 . Basisadresse (n) des CT-Speicherbereiches in 0506 zur Lo- 
kalisierung der Konfigurationen'. 

2. Basisadresse (n) von Datentransfers mit 0505. 

3. 10 Adressen von Datentramsfers mit 0508. 

4. Synchronisationsinformationi z.B. ZurEicksetzen, anhalten, 
starten der VPU. 

5. Statusinformation der VPU, z.B. Fehler oder Zustand der 
Datenverarbeitung. 
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Die Synchronisation der CPU und VPU erfolgt durch Polling von 
Daten und/oder bevorzugt durch Interruptsteuerung (0512) . 



Pigur 6 zeigt eine mogliche Ausgestaltung der Interf acestruk- 
tur einer VPU zur Binbindung in ein System ihnlich Figur 5. 
Dazu werden der VPU ein Speicher/DMA- und/oder lO-Interface 
zum Datentransfer zugeordnet (0601), ein weiteres System- 
Interface (0602) ul>emiinrat die Ablauf steuerung wie z.B. das 
Verwalten von Interrupts, das Starten/Stoppen der Verarbei- 
tirng, Austausch von Fehlerzustanden, etc.. . 
Das Speicher/im- und/oder 10- Interface wird an einen Spei- 
cherbus und/oder lO-Bus angeschlossen. 

Das System- Interface wird vorzugsweise an einen lO-Bus ange- 
schlossen, kann jedoch alternativ oder zusStzlich entsprechend 
0511 auch an einen Speicher angeschlossen sein. 

Die Interfaces (0601, 0402) konnen zur Anpassiang von \mter- 
schiedlichen Arbeitsfrequenzen von CPU xmd/oder VPU und/oder 
System ausgestaltet sein, beispielsweise kann das System bzw. 
die CPU mit zB derzeit 500MHz und die VPU mit 200MHz arbeiten- 

Die Interfaces kdnnen eine. Ubersetzung der Busprotokolle 
durchfuhren, beispielsweise kann das VPU interne .Protokoll auf 
ein ext ernes AMBA-Busprotokoll umgesetzt werden- Sie bewirken 
also Busprotokollubersetzungsmittel und/oder sind fQr die Bus- 
protokollObersetzung ausgebildet, insbesondere die Busproto- 
kollubersetzung zwischen intemem VPU-Protokoll und bekaxmtem 
Busprotokoll . Es ist auch moglich, eine Konvertierung direkt 
auf CPU- interne Busprotokolle vorzusehen. 

Das Speicher/DMA- und/oder 10- Interface unterstiitzt den Spei- 

cherzugriff der CT auf einen extemen Speicher, der vorzugs- 
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weise direkt (memory mapped) erfolgt. Der Datentransfer der 
CT(s) und/oder PAC(s) kann gepuffert z.B. fiber FlPO-Stufen er- 
folgen. Extemer Speicher kann direkt angesprochen und adres- 
siert werden, weiterhin kdrmen DMA interne xind/oder exteme 
DMA- Transfers durchgefiihrt werden. 

tiber das System- Interface erfolgt die Steuerung der Datenver- 
arbeitung, wie beispielsweise die Initialisierung und/oder der 
Start von Konf igurationen. Des weiteren werden Status und/oder 
Pehlerzustande ausgetauscht , Interrupts fur die Steuerung und 
Synchronisation zwischen den CP's und einer CPU kdnnen unter- 
statzt werden. 

Das System- Interface kann VPU- interne Protokolle derart kon- 
vertieren, dass diese auf exteme (Standard) -Protokolle umge- 
setzt werden (z.B. AMBA) . 

Bin bevorzugtes Verfahren zur Codegenerierung fur das be- 
schriebene System ist in anderen Teilen dieser Anmeldung be- 
schrieben. Das Verfahren beschreibt einen Compiler, der Pro- 
grammcode in Code fiir eine CPU und Code fur eine VPU zerteilt, 
Nach unterschiedlichen VerfsJiren wird die Zerlegung auf die 
unterschiedlichen Prozessoren durchgefxihrt . In einer besonders 
bevorzugten Ausfuhrung werden dad^ei die jeweiligen zerlegten 
Codes urn die Interf ace-Routinen zur Komraunikation zwischen. CPU 
und VPU erweitert. Die Erweiterung kann automatisch durch den 
Compiler erfolgen. 

Die nachfolgende Tabellen zeigen beispielhaf te Kommunikationen 

zwischen einer CPU und einer VPU. Den Spalten sind die jewei- 

lig aktiven Funktionseinheiten zugeordnet: CPU, System-DMA .und 

DMA-Interface (EDMA) bzw. Speicher- Interface {Speicher- I/P) , 

System- Interface (System- I/F, 0602), CT's, sowie die PAC. In 

den Zeilen sind die einzelnen Zyklen in ihrer Ausfuhrungsrei- 
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henfolge eingetragen. Kl referenziert eine auszufuhrende Kon- 
figuration 1- 



Die erste Tabelle zeigt beispielsweise einen Ablauf bei Ver- 
wendijuig der System-DMA (EDMA) zum Datentransfer: 
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Es ist zu erw^hnen, dass die Synchronisation zwischen der EDMA 
und der VPU automatisch uber das Interface 0401 erfolgt, d.h. 
DMA-Tranfers finden nur statt, wenn die VPU dafur bereit ist. 



In einer zweiten Tabelle ist beispielsweise ein bervorzugter 
optimierter Ablauf dargestellt. Die VPU besitzt selbst direk- 
ten Zugriff auf den Konf igurationsspeicher (0306) . Desweiteren 
werden die Datentransf ers durch DMA-Schaltiang innerhalb der 
VPU ausgefuhrt, die beispielsw-ise fest implementiert sein 
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kdnnen \md/oder durch die Konfiguration von konfigurierbaren 
Teilen der PAC entetehen*. 
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Der Aufwand fQr die CPU ist minimal* 

Zusammenfassend befafit sich die vorliegende Erfindung mit Ver- 
fahren, die eine Obersetziing einer klassischen Hochsprache wie 
Pascal, C, C++, Java, etc. auf eine rekonf igurierbare Archi- 
tektur ermoglicht. Das Verfahren ist derart ausgelegt, daE nur 
die jevreils filr die rekonf igurierbare Zielarchitektur geeigne- 
ten Teile des zu Obersetzenden Programmes extrahiert werden. 
Die verbleibenden Teile des Programmes werden auf eine konven- 
tionelle Prozessorarchitektur ubersetzt. 

In Figur 7 sind aus Grunden der Ubersichtlichkeit nur die re- 

levanten Komponenten (i.b. der CPU) aufgezeigt sind, wobei ty- 
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pisch eine wesentliche Zahl weiterer Komponentfen und Netzwerke 
vorhanden sein wird. 



Eine bevorzugte Implementierung wie beispielsweise in Figur i 
dargestellt kann imterschiedliche Datentransf era zwischen ei- 
ner CPU (0701) und VPU (0702) vorsehen. Die auf der VPU auszu- 
fOhrenden Konf igurationen werden durch den Instruktionsdekoder 
(0705) der CPU selektiert, der bestimmte far die VPU bestimmte 
Instruktionen erkennt und die CT (0706) derart ansteuert, dass 
diese die entsprechenden Konf igurationen aus einem der CT zu- 
geordneten Speicher (0707) - der insbesondere mit der CPU ges- 
hared werden Oder derselbe wie der Arbeitsspeicher der CPU 
sein kann, in das Array aus PAEs (PA, 0108) ladt. 

Es sind CPU-Register (0703) vorgesehen, urn bei einer Register- 
kopplung Daten zu entnehmen, zu verarbeiten und in ein CPU- 
Register zuruckachreiben. b FGr die Datensynchronisation ist 
ein Statusregister (0704) vorgesehen, Weiter ist ein Cache 
vorgesehen, der daffir vorgesehren ist, daS wenn Daten ausge- 
tauscht werden sollen, die Jcurz zuvor von der CPU verarbeitet 
wurden, diese voraussichtlich noch im Cache (0709) der CPU 
liegen bzw. sof.ort anschliessend von der CPU verarbeitet wer- 
den. 



Der exteme Bus ist mit (0710) bezeichnet und es werden dar- 
(iber zB aus einer damit verbundenen Datenquelle (z.B. Spei- 
cher, Peripherie) gelesen, bzw. an den extemen Bus und der 
damit verbundenen Datensenke (z.B. Speicher, Peripherie) ge- 
schrieben. Dieser Bus kann insbesondere derselbe wie der ex- 
teme Bus der CPU sein (0712 & gestrichelt) . 

Ein Protokoll (0711) zwischen Cache und Bus ist in^lementiert, 
das fur einen korrekten Inhalt des Caches sorgt. Mit (0713) 
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ist ein FPGA {0713} bezeichent, der mit der VPU gekoppelt sein 
kann, um feingranulare Datenverarbeitung zu ermoglichen 
und/oder ein flexible adaptierbare Interface (0714) (z.B. di- 
verse serielle Schnittstellen (V24, USB, etc.), diverse paral- 
lele Schnittstellen, Festplattenschnittstellen, Ethernet, Te- 
lekommunikationsschnittstellen (a/b, TO, ISDN, DSL, etc)) zu 
weiteren Baugruppen und/oder dein externen Bussystem (0712) zu 
ermoglichen. 

Entsprechend Figur 8 befindet sich Speicherbereich des Be- 
triebssystems eine Tabelle oder verkettete Lists (LINKLIST, 
0801) , die auf sSmtliche VPUCALL-Tabellen (0802) in der Rei- 
henfolge ihrer Erstellung zeigt. 



49 



wo 02/103532 



PCT/EP02/06865 



PatentansprC^che 

1. Veirfahren zur Obersetzung von Programmen auf ein System be- 
stehehd aus wenigstens einem ersten Prozessor und einer re- 
konfigurierbaren Binheit, dadurch gekennzeichnet, dafi die 
Codeteile/ die fur die rekonfigurierbafe Einheit geeignet 
sind, bestimmt uiid extrahiert und/oder separiert wird, wo- 
bei verbleibender Code zur Abarbeitung durch den ersten 
Prozessor bestimmt wlrd« 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dafi dem 
ffir den Prozessor extrahierten Code Interface-Code zugef^igt 
wird, der eine Kommunikation zwischen Prozessor und rekpn- 
figurierbarer Einheit entsprechend des Systemes ermoglicht. 
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3. Verfahren nach einera der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daS detn fur die rekonf igurierbarer Einheit 
extrahierten Code solcher Interface -Code zugefQgt wird, der 
eine Kommunikation zwischen Prozessor und rekonf igurierba- 
rer Einheit entsprechend des Systems ermoglicht. 

4. Verfahren nach einem der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, dafi der zu extrahierende Code aufgriind von 
automatisierten Analysen festgelegt wird. 

5. Verfahren nach einem der vorhergehenden Ansprfiche, dadurch 
gekennzeichnet, da£ Hlnweise im Code zur Feststellung des 
zu extrahierenden Code automatisch ausgewertet werden. 

6. Verfahren nach einero der vorhergehenden Anspruche, dadurch 
gekennzeichnet, da& der zu extrahierende Code aufgrund von 
Aufrufen von Unterprogrammen festgestellt wird. 

7. Verfahren nach einem der vorhergehenden Anspr^Lche, dadurch 
gekennzeichnet, daS ein Interface- Code vorgesehen wird, 
der eine Speicherkopplung (Shared-Memory) vorsieht 
und/oder eine Regie terkopplung und/oder eine Kopplung mit- 
tels' eines- Netzwerkes bewirkt . 

8. Verfahren nach einem der vorhergehenden Ahsprtlche, dadurch 

gekennzeichnet, daS der extrahierte Code und/oder mit einer 
gegebenen Extraktion erzielbaren Resultate analysiert wird 
und gegebenenfalls die Extraktion mit neuen verbesserten 
Parametem emeut gestartet wird. 

9. Verfahren nach einem der vorhergehenden Ansprflche, dadurch 
gekennzeichnet, dafi dera extrahierten Code Steuer-Code zur 
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Verwaltung und/oder Steuerung und/oder Kommunikation der 
Entwicklungssysteme zugefugt wird. 



10. Verfahren nach einem der vorhergehenden Anspruche, worin 
der erste Prozessor eine konventionelle Prozessorarchitek- 
tur aufweist, insbesondere ein Prozessor mit von - Neuraaim 
- und/oder Harwardarchitektur, Kontroller, CISC-, RISC-, 
VLIW-, DSP- Prozessor. 

11. Verfahren insbesondere nach einem der vorhergehenden An- 
sprache zur Dbersetzung von Programmen auf ein System be- 
stehend aus einem Prozessor \and einer rekonf igurierbaren 
Einheit, dadurch gekennzeichnet , dafi die Codeteile, die f\ir 
die rekonfigurierbare Einheit geeignet sind, extrahiert 
werden, der verbleibende Code derart extrahiert wird, dafi 
er mittels eines beliebigen gewdhnlichen unmodif izierten 
fQr den Prozessor geeigneten Compilers ubersetzbar ist. 

12. Vorrichtxing zur Datenverarbeitung mit wenigstens einem 
herkommlichen Prozessor und wenigstens einer rekonf igu- 
rierbaren Einheit, dadurch gekennzeichnet, daS ein Mittel 
zum Informationsaustausch, insbesondere von Daten- und 
Statusinformation, zwischen • herkdmmlichem Prozessor xind 
rekonf igurierbarer Einheit aufweist, wobei das Mittel so 
ausgebildet ist, daS ein Daten- und Statusinformation zwi- 
schen denselben wShrend der Abarbeitung eines oder mehrere 
Programme mdglich ist xmd/pder ohne daS insbesondere die 
Datenverarbeitung auf dem rekonf igurierbaren Prozessor 
und/oder dem herkdmmlichen Prozessor signif ikant unterbro- 
chen werden mufi. 
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Titel: Verfahren zum Obersetzen von Programmen fur rekon- 

figurierbare Architekturen 

1; Exnleittmg 

Die vorliegende Erf indung betrif ft das Oberbegriff lich Bean- 
spruchte. Damit befafit sich die vorliegende Erf indung mit der 
Frager wie rekonfigurierbare Architekturen optimal verwendet 
warden konnen und insbesondere damit/ wie Anweisungen in einer 
gegebenen Hochsprache in rekonf igurierbaren Architekturen op- 
tiinal zur AusfQhrung gebracht verden k5nnen. 

Urn in sog, Hochsprachen geschriebene Anweisungezl zur Handha- . 
bung von Daten (Programme) in einer jeweiligen, zur Datenhand- 
habung verwendeten Architektur zur Ausfiihrung zu bringen, sind 
sog. Compiler bekannt, die die Anweisungen der Hochsprache in 
an die verwendete Architektur besser angepafite Anweisungen 
(ibersetzen. Compiler, die dabei hochparallele Architekturen 
besonders untersttitzen, sind demgemSB parallelisierende Compi- 
ler. 

Parallelisierende Compiler nach dem Stand der Technik verwen- 
den far gew5hnlich spezlelle Konstrukte wie Semaphore und/oder 
andere Verfahren zur Synchronisation. Dabei werden typischer- 
weise technologiespezifische Verfahren verwendet. Bekannte 
Verfahren sind nicht geeignet, urn funktional spezifizierte Ar- 
chitekturen mit dem zugehdrigen Zeitverhalten und imperativ 
spezifizierte Algorithem zu kombinieren. Daher liefern die 
verwendeten Methoden nur in Spezialfallen zufriedenstellende 
L5sungen. 

ERSATZBLATT (REGEL 26) 
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Coi!5>iler fur rekonfigurierbare Architektufen, insbesondere fQr 
rekonflgurierbaren Prozessoren/ verwenden fUr gew5hnllch Ma- 
kros, die speziell fur die begtiirante rekonfigurierbare Hard- 
ware erstellt wurden, wobei fOr die Erstellung der Makros zu- 
mist Hardwarebeschreibungsspracben wle z^B. Verilog, VHpL 
Oder System-C verwendet werden. Diese Makros werden dann von 
einer gewShnlichen Hochsprache (z.B. C, C++) aus dem Programza- 
fluss heraus aufgerufen (instantiiert) ^ 

Compiler fiir Parallelrechner sind bekannt^ die auf einer grob- 
graniilaren Struktur, zumeist basierend auf kompletten Funktio- 
nen oder Threads Prograiranteile auf mehrere Prozessoren abbil- 
den. 

Weiterhin sind vektorisierende Compiler bekannt, die eine 
weitgehende linear e batenverarbeitung, wie z.B. Berechnungen 
groBer Ausdrtlcke in eine vektorisierte Form umwandeln und da- 
mit die Berechnung auf supers kalaren Prozessoren und Vektor- 
prozessoren (z.B. Pentium, Cray) ermaglichen. 

Vorliegend wird ein Verfahren zur automatischen Abbildung von 
funktional oder in^erativ formulierten Rechenvorschriften auf 
unterschiedliche Zieltechnologien beschrieben, insbesondere 
auf ASICs, rekonfigurierbare Bausteine (FPGAs, DPGAs, VPUS/ 
ChessArray, KressArray, Chameleon, etc.; im folgenden unter 
dem Begrif f VPU zusammengefaBt) , sequentielle Prozessoren 
(CISC- /RISC-CPUs, DSPs, etc.; im folgenden unter dem Begrif f 
CPU zusammengefafit) und parallele Rechnersysteme (SMP, MMP, 
etc.) . Hingewiesen wird insbesondere in diesem Zusammenhang 
auf die folgenden Schutzrechte und Patentanmeldungen desselben 
Anmeldexs: P 44 16 881.0-53, DE 197 81 412.3, DB 197 81 483.2, 
OS 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53, 
DE 198 80 129.7, DE 198 61 088.2-53, DB 199 80 312.9, 
PCT/DE 00/01869, DE 100 36 627.9-33, DB 100 28 397.7, 
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DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516, 
EP 01 102 674.7, PACT13, PACT17, PACT18, PACT22, PACT24, 
PACT25, PACT26US, PACT02, PACT04, PACT08, PACTIO, PACT15, 
PACT18(a)/ PACT 27^ PACT19. Difese sind hiermit zu Offenba- 
ruiigSzwecken vollumfanglich eingegliedert. 

VPUs bestehen grundsStzlich aus einer mehrdimensionalen homo- 
genen oder inhomogenen, flachen oder hierarchischen Anordung 
(PA) von Zellen (PAEs)^ die beliebige Funkt±onen, i.b. logi- 
sche und/oder arithmetische FunJctionen und/oder. Speicherfunk-. 
tionen und/oder Netzwerkfunktionen ausfOhren kdnneri. Den PAEs 
ist typisch eine Ladeeinheit (CT) zugeordnet, die die Funktion 
der PAEs durch Konfiguration und ggf • Rekonfiguration be- 
stiimnt • 

Das Verfahren basiert auf einem abstrakten parallelen Maschi- 
nenmodell, das neben deiu endlichen Autoiaaten auch imperative 
Problemspezifikationen integriert und eine effiziente algo- 
rithmische Ableitung einer Implementierung auf unterschiedli- 
Che Technologien ermaglicht. 

Folgende Compiler klas sen sind nach dem Stand der Technik be- 
kannt: 

Klassische Compiler, die hSufig Stack-Maschinen-Cbde generie- 
ren und fUr sehr einf ache Prozessoren geeignet waren, die im 
Wesentlichen als normale Sequenzer ausgestaltet sind. (vgl. 
N.Wirth, Compilerbau, Teubner Verlag) . 

Vektorisierender Compiler bauen weitgehend linearen Code, der 
auf spezielle Vektorrechner oder stark gepipelinte Prozessoren 
abgestimmt ist. Ursprxinglich waren diese Compiler far Vektor- 
rechner wie CRAY verftlgbar. Moderne Prozessoren wie Pentium 
benatigen aufgrund der langen Pipelinestruktur ^hnliche Ver- 
fahren. Da die einzelnen Rechenschritte vektorisiert (gepipe- 
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lined) ablaufen ist der Code sehr viel effizienter. Allerdxngs 
bereitet der bedingte Sprung Probleme ftir die Pipeline. Daher 
ist eine Sprungvorhersage sinnvoll, die ein Sprungziel an- 
nimmt. Ist die Annahrae f alsch,/^ muss jedoch die gesamte Verair- 
beitungspipeline gelbscht warden. Mit anderen Wort en ist jeder 
Sprung fiir diese Compiler problematisch; eine Parallel verar- 
beitung im eigentlichen Sinn ist nicht gegeben. Sprungvorher- 
sagen und Shnliche Mechanismen erfordem einen erheblichen Zu- 
satzaufweuid an Hardware. 

Grobgranulare parallele Compiler existieren im eigentlichen 
Sinne kaum, die Parallelitat wird typischerweise durch den 
Programraierer oder das Betriebssystem markiert und verwaltet, 
also beipielsweise bei MMP-Computersysteme wie verscheiden IBM 
Architekturen, ASCI Red, etc. zumeist auf Thread-Ebene durch- 
geftthrt. Ein Thread ist ein weitgehend unabhSLngiger Prograiran- 
block Oder gar ein anderes Programm. Threads sind daher grob- 
granular einfach zu parallelisieren. Die Synchronisation und 
Datenkonsistenz ist vom Progranmierer bzw. dem Betriebssystem 
sicherzustellen. Dies ist aufwendig zu programmieren und er- 
fordert einen wesentlichen * Anteil der Rechenleistung eines 
Parallelrechner. Zudem ist durch diese grobe Parallelisierung 
nur ein Bruchteil der eigentlich moglichen Parallelitat tat- 
sachtlich nutzbar. 

Feingranulare parallele (z.B. VLIW) Compiler versuchen die 
Parallelitat feingraunlar in VLIW Rechenwerke abzubilden, die 
mehrere Rechenoperationen in einem Takt parallel ausftihren 
k5nnen aber einen gmeinsamen Registersatz besitzen. Ein we- 
sentliches Problem stellt dieser limitierte Registersatz dar, 
da er die Daten fOr sctatliche Rechenoperationen bereitstellen 
muss. Zudem erschweren DatenabhSngigkeiten und inkonsistente 
Lese/Schreiboperationen (LOAD/STORE) die Parallelisierung- 
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Rekonfigurierbare Prozessoren weisen elne groBe Anzahl an un- 
abhangigen Rechenwerken auf , die typisch in einem Feld ange- • 
ordnet sind* Diese sind typisch nicht durch einen gemeinsamen 
Registersatz, sondern durch BufSse miteinander verbunden. Da- 
durch lassen sich eiherseits leicht Vektorrechenwerke aufbaii- 
en, andererseits k5nnen auch einfach.parallele Operationen 
durchgeflihrt werden. Durch die Busverbindungen warden entgegen 
der herkoinmlichen Regis terkonzepte DatenabhSngigkeiten aufge- 
lost. 

Die Aufgabe der vorliegenden Erfindung besteht darin, Neues 
fiir die gewerbliche Anwendung bereitzustellen. 

Die Losung dieser Aufgabe wird in unabhSngiger Form bean- 
sprucht. Bevorzugte Ausfuhrungsformen finden sich in den Un- 
teranspriichen . 

Es wird also vorgeschlagen, ffir einen Conqpiler fOr rekonfigu- 
rierbare Prozessoren die Konzepte von vektorisierenden Compi- 
lem und parallelisierenden (z.B. VLIW) Conqpilern zugleich an- 
zuwenden und somit auf feingranularer Kbene zu Vektorisieren 
und parallelisieren. 

Bin wesentiicher Vorteil besteht darin, dass der Compiler 
nicht auf eine f est vorgegebene Hardware struktur abbilden 
muss, sondern die Hardwarestruktur ndt dem erfindungsgemafien- 
Verfahren so konf igurieirt werden kann, dass sie optimal fOr 
die Abbildung des jeweiligen compilierten Algorithmus - geeignet 
ist, 

2> BesGhreibunq 

Als Grundlage zur Abarbeitung praktisch jeder Methodik zur 
Speziflzierung von Algorithmen wird der endliche Automat ge- 
nutzt. Die Struktur eines endlichen Automaten ist in Figur 1 
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abgebildet. Bin einfacher endlicher Automat zerfailt in ein 
kombinatorisches Netz und elne Registerstufe zum Zwischenspei- 
cheim von Daten zvlschen den einzelnen Datenverarbeitungszy- 
klen. 

Ein endlicher Automat fOhrt eine Anzahl rein kombinatorischer 
(also z.B. logischer vmd/oder arithmetischer) Datenmanipula- 
tionen aus, um danach einen stabilen Zustand zu erreichen, der 
in einem Register (satz) reprSsentiert wird, Basierend auf die- 
sent stabilen Zustand wird entschieden, welcher nSchste Zustand 
im nachsten Verarbeitungsschritt erreicht werden soil und so- 
mit auch, welche kombinatorischen Datenmanipulationen im nSch- 
sten Schritt durchgefiihrt werden sollen. 

Beispielsweise repr^sentiert ein Prozessor oder Sequenzer ei- 
nen endlichen Automaten. In einem ersten Verarbeitungsschritt 
kann eine Subtraktion von datendurchgeffihrt werden. Das Ergeb- 
nis wird gespeichert. Im nachsten Schritt ksuin basierend auf 
dem Ergebnis der Subtraktion ein Sprung durchgeftbhrt werden, 
der je nach Vorzeichen des Ergebnisses in eine andere Weiter- 
verarbeitung ftthrt. 

Der endliche Automat ermoglicht die Abbilduiig komplexer Algo- 
rithmen auf beliebige sequentielle Maschinen, wie in Figur 2 
abgebildet. Der daxgestellte kbic^lexe endliche Automat besteht 
aus einem kon^lexen kombinatorischen Netz, einem Speicher zmx 
Ablegen von Daten und einem Adressgenerator zum Adressieren 
der Daten im Speicher. 

Nun kann jedes beliebige sequentielle Programm grundlegend als 
endlicher Automat interpretiert werden, wobei aber zumeist ein 

r 

sehr groBes kombinatorisches Netz entsteht. Bei der Program- 
mierung klassischer "von Neumann^'-Architekturen - also bei al- 
ien CPUs - werden daher die kombinatorischen Operationen in 
eine Folge von jeweils einzelnen einfachen, fest vorgegebenen 
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Operationen (Opcodes) auf CPU-interne Register zerlegt. Durch 
ciiese Zeriegung entstehen Zustande zur Steuerung der in eine 
Folge zerlegten kombinatorischen Operation, die aber innerhalb 
der ursprUnglichen kombinatori^schen Operation per se nicbt 
vorhanden sihd> bzw. nicht bendtigt werden. baher sind jedoch 
d±e abzuarbeitenden Zustahd^ einer von Nermann Maschinen 
grundsatzlich von den algorithm schen Zustanden eines kombina- 
torischen Netzes, also den Registern endlicher Automaten zu 
imterscheiden. 

Es wurde nun erkannt, dass die VPU-Technologie (wie sie im We- 
sent lichen durch einige oder alle der Schriften PACTOl, 
PACT02, PACT03, PACT04, PACT05, PACT08, PACTIO, PACT13, 
PACT17, PACT18, PACT22, PACT24 definiert ist, die durch Bezug- 
nahme vollumfanglich eingegliedert sind) im Gegensatz zu den 
starren Opcodes von CPUs ermaglichtr kon5>lexe Instruktionen 
entsprechend eines abzubildenden Algorithiaus wie in flexiblen 
Konfigurationen hineinzukompilieren. 



2.1 Arbei-bsweige des Compilers 

Besonders vorteilhaft ist bei der Arbeitsweise des Compilers, 
wenn die komplexen Instruktionen derart generiert werden, daB 
diese mdglichst lange in der PAE-Matrix ohne Rekonf iguration 
ausgefOhrt wird. 

Der Compiler generiert weiterhin den endlichen Automaten be- 
vorzugt aus dem imperativen Quelltext derart, daB er der je- 
weiligen PAK-Matrix besonders gut angepasst ist, also solche 
Operationen darin vorgesehen werden, die die typisch grobgra- 
nularen Logikkreise (ALUs Btc.) , gegebenenfalls auch vorhande- 
ne feingranulare Blemente (FPGA-Zellen in der VPU, statemachi- 
nes etc.) besonders effizient nutzen. 
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Der coiapilererzeugte endliche Automat wird darai in Konfigura- 
tionen zerlegt. 

Das Abarbeiten (InterpretiererjO des endlichen Automaten ge- 
schieht auf einer VPU derart/daB die generierten Konfigura- 
tionen succe3ive aiif die PAE-Matrix abgebildet werden und die 
Arbeitsdaten und/oder Zustande/ die zwischen den Konfiguratio- 
nen zu iibertragen sind, in Speicher abgelegt werden. Dazu kann 
das aus PACT04 bekannte Verfahren bzw. die entsprechende Ar- 
chitektur verwendet werden. Dieser Speicher wird vom Compiler 
bestiiomt beziehungsweise vprgesehen. Es reprSsentiert eine 
Konfigiiration dab'ei eine Mehrzahl von Instruktionen; eine Kon- 
figuration bestimmt zugleich ftir eine Vielzahl von Takten die 
Arbeitsweise der PAE-Matrix^ wahrend dieser Takte wird eine 
Vielzahl von Daten in der Matrix verarbeitet; diese stammen 
aus einer VPU externen Quelle und/oder einem internen Speicher 
und werden an eine externe Quelle und/oder einen internen 
Speicher geschrieben. Die internen Speicher ersetzen dabei den 
Registersatz einer CPO nach dem Stand der Technik .derart^ dafi 
z.B. ein Register durch einen Speicher reprSsentiert wird, wo- 
bei nicht ein Datenwort je Register gespeichert wird, sondern 
ein gesamter Datensatz je Speicher. 

Wesentlich kann auch sein, daB die Daten und/oder Zustande der 
Verarbeitung einer ablauf enden Konf igtiration compilerbestimmt 
in die Speicher abgelegt werden und somit der nclchsten ablau- 
f enden Konf igurat ion zur VerfQgung stehen. 

Ein bedeutender Unterschied zu Compilern, die auf Instruk- 
tionsbasis parallelisieren, besteht soniit darin, daB das Ver- 
fahren die PAE-Matrix derart konfiguriert und rekonfiguriert, 
dass eine konfigurierte Folge von kombinatorischen Netzen auf 
einer VPU emuliert wird, wahrend herk6nimliche Compiler gelade- 
ne Folgen von Instruktionen (Opcodes) kombinieren, wobei eine 
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Instruktion als ein kombinatorisches Netz betrachtet warden 
kann. 



2.2 Aasffihnihqsbeiapiel WHIIiE^Sprache 

Im Fblgenden sbll die Funktionsweise des Compilers anhand ei^ 
ner einfachen Sprache beispielhaft verdeutlicht warden. Dabei 
wird von einer Sprache ausgegangen, die in ihren Griindlagen 
bereits bekannt ist, wobei in einer bekannten Verof fentlichung 
[Referenz "Doktorarbeit Armin NQckel"] jedoch lediglich. die 
Abbildung einer Funktion auf ein statisches kombinatorisches 
Netz beschrieben wird, wShrend ndt der Erfindung nun die Ab- 
bildung auf Konfigurationen erfolgt, die dann in einer zeitli- 
chen Reihenfolge entsprechend des Algorithmus tmd der sich 
wahrend der Verarbeitung ergebenden ZustSnde auf die PAE- 
Matrix abgebildet werden. 

Die Programnder sprache geht davon aus, dass neben einfachen 
logischen und/oder arithmetischen VerknUpfungen ein Befehl 
"WHILE" existiert, der mit folgender Syntax definiert ist: 
WHILE... 

M5gliche Konstrukte sind dandt: Anweisung 

Folge von Anweisungen 
Schleife 

Eine Anweisung Oder eine Folge von Anweisungen ist durch das 
beschriebene Compiler-Verfahren auf ein kombinatorisches Netz 
abbildbar . 

Figor 3a zeigt ein kombinatorisches Netz mit den dazugehdren- 
den Variablen. Dabei kann sich der Inhalt ein und derselben 
Variable (z.B. kl) von einer Stufe (0301) des Netzes zur nSch- 
sten (0302) Sndern. 
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Diese VerSnderung ist beispielsweise fiir die Zuweisung 

xl := xl + 1 

in Figur 3b dargestellt* 



Zur Adres9ierurig zum. Leseii der Operanden und zum Speicherji der 
Ergebnisse kSnnen nun Adressgeneratoren mit dem Jcombinatori- 
schen Netz der Zuweisung synchronisiert werden. Mit jeder ver- 
arbeiteten Variable werden entsprechende neue Adressen fiir 
Operanden und Ergebnisse generiert (Figur 3c) . Die Art des 
Adressgenerators ist prinzipiell beliebig und hSngt von den 
Adressierungssdhematas der compilierten Applikation ab. 
FQr Operanden und Ergebnisse kannen gemeinsame, konibinierte 
Oder vollstandig unabhSngige Adressgeneratoren implementiert 
werden. 

Typischerweise werden bei der Datenverarbeitung wie im vorlie- 
genden Datenverarbeitungsmodell eine Mehrzahl von Daten inner- 
halb einer bestimmten Konfiguration der .PAEs verarbeitet. Be- 
vorzugt ist der Compiler daher ftir die in vielen, wenn nicht 
den meisten Anwendungen mSglichen einf achen FIFO-Modus ausge- 
legt, der zumindest- ftir die Datenspeicher anwendbar ist, die 
innerhalb dieser Beschreibung zum Speichern von Daten und Zu- 
standen der Datenverarbeitimg (quasi als Ersatz eines gewehn- 
lichen Registersatzes herkommlicher CPUs) dienen^ Mit anderen 
Worten dienen Speicher der temporSren Speicherung von Varia- 
blen zwischen den Konf igurationen . Auch hier ist eine Konfigu- 
ration ahnlich einer Instruktion eines normalen Prozessors und 
die Speicher (insbesondere eine Mehrzahl) sind vergleichbar 
mit dem Registersatz eines normalen Prozessors. 



2.2-3 Folqen von Anweisunqen 

Eine Folge der beispielhaften Zuweisung ISfit sich wie folgt 
generieren (Figur 4a) : 
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xl :« 0; 
WHILE TRUE DO 

Xl :« xl + 1; 

Diisse Folge ISJit sich nunmehr Mtteis einer Zuweisung gemafi 
2.2.1 und Adressgeneratoren fQr Operahden und Ergebnisse ab- 
bildeh, - 

Endllche Folqen 

Der Vollstandigkeit halber soil eine besondere Ausgestaltung 
von Folgen abseits der definierten Konstrukte der WHILE Spra- 
che diskutiert werden. Eine endliche Folge der beispielhaften 
Zuweisung I'd&t sich wie folgt generieren: 
FOR i:=l TO 10 
xl := xl + 1; 

Eine derartige Folge iSBt sich durch zwei Artea in^lementie- 
ren: 

a) Durch Generierung eines Addierers zur Berechnung von i ent- 
sprechend des WHILE-Konstruktes. (siehe 2.2.4) und eines 
weiteren Addierers zur Berechnung von xl. Die Folge wird 
als Schleife abgebildet und iterativ berechnet (Figur 5a) . 

b) Durch Auswalzen der Schleife, wodurch die Berechnung von i 
als Funktion entfailt. Die Berechnung von xl wird i-mal in- 
stantiiert und als Pipeline aufgebaut, wodurch i nacheinan- 
der geschaltete Addierer entstehen (71gux 5b) . 

2.2 > 4 Bedinqunqen 

Bedingungen lassen sich mittels WHILE ausdrGcken. Beispiels- 

weise: 

xl := 0; 

WHILE xl < 10 DO 
xl :« xl + 1; 

Die Abbildung generiert eine zusatzliche PAE zur Verarbeitung 
des Vergleiches. Das Vergleichsergebnis wird durch ein Sta- 
tussignal reprSsentiert (vgl. Trigger in PACT08), das von den 
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die Anweisung verarbeitenden PABs und den Adressgeneratoren 
ausgewertet wird. 

Die resultierende Abbildung ist in Figur 4b dargestellt. 

bufch die Auswertmg der Bedingtmg (hier WHILE; genereli und 
einleuchtenderweise aiich andere Anweisungen wle IF;. CASE rea^- 
lisierbar) wird ein Status generiert, der der nachfolgenden 
Datenverarbeitung zur Verfflgung gestellt werden kann (DE 197 
04 728.9) und/oder an die CT oder eine lokale Ladesteuerung 
(DE 196 54 846.2) gesendet werden kann, die daraus Information 
Ober den weiteren ProgranimfluB und evtl. anstehende Rekonfigu- 
rationen ableitet. 

2.2.5 Grundleqendes Verfahren 

Entsprechend den vorherigen Verfahren wird jedes Programm in 
ein System abgebildet, das wie folgt aufgebaut ist: 

1. Speicher fQr Operanden (vgl. Register einer CPU) 

2. Speicher ftir Ergebnisse (vgl. Register einer CPU) 

3. Netzwerk aus a) Zuweisungen und/oder b) Vergleichen- 
Anweisungen, also Bedingungen wie z.B. IF, CASE, Schleifen 
(WHILE, FOR, REPEAT) 

4. Optionalen Adressgenerator (en) zur Ansteuerung der Speicher 
nach 1 und 2. 



2.2.6 Umqanq mit Zustanden 

Es wird nun fur die Zwecke des beschriebenen Compilers zwi- 
schen algorithmisch relevanten und irrelevanten ZustMnden un- 
terschieden. Zusttode werden in der VPU-Technologie far ge- 
wOhnlich durch Statussignale (z.B. Trigger in PACT08) und/oder 
Handshakes (z.B. RDY/ACK in PACT02) dargestellt. Genereli kCn- 
nen Zustande (v. a. in anderen Technologien, wie fPGAs, DPGAs, 
Chameleon-Bausteinen, Morphias, etc.) durch beliebige Signale, 
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Signalbundel imd/oder Register dargestellt werden. Das offen- 
barte Compilierverfahren kann auch auf solche angelegt werden^ 
obwohl wesentliche Teile der Beschrelbung bevorzugt auf die 
VPU fokussieren. 

Reievante Zustande sirid innerhalb des Algorithmtis notwendig um 
dessen korrekte Funktion zu beschrelben. Sie sind fOr den Al- 
gorithmus wesentlich. 

Irrelevante Zustande entstehen durch die verwendete Hardware 
und/oder die gew^hlte Abbildung oder aus anderen sekundaren 
Grunden. Sie sind damit f0r die Abbildung (also die Hardware) 
wesentlich. 

Lediglich die relevant en Zustande mUssen mit den Daten erhal- 
ten werden. Daher werden diese zusainmen mit den Daten in den 
Speichern abgelegt, da sie entweder als Ergebnis der Verarbei- 
tung mit den Daten auftraten Oder als Operanden mit den Daten 
ftir den nachsten Verarbeitungszyklus notwendig sind. 

Irrelevante Zustande sind dagegen nur Srtlich und/oder zeit- 
lich lokal notwendig und mQssen daher nicht gespeichert wer- 
den. 

Beispiel: 

a) Die Zustandsinformation eines Vergleichs ist ftir die weite- 
re Verarbeitung der Daten relevant, da dieser die auszuftth- 
renden Funktionen bestimmt. 

b) Angenoinmen, ein sec[uentieller Dividierer entsteht bei- 
spielsweise durch Abbildung eines Divisionsbefehles auf ei- 
ne Hardware, die nur die sequentielle Division lanterstQtzt. 
Dadurch entsteht ein Zustand, der den Rechenschritt inner- 
halb der Division kennzeichnet . Dieser Zustand ist irrele- 
vantr da far den Algorithmus nur das Ergebnis (also die 
ausgeftihrte Division) erforderlich ist- In diesem Fall wer- 
den also lediglich das Ergebnis und die Zeitinformation 
(also die Verftlgbarkeit) benatigt. Der Compiler unterschei- 
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det solche relevant© und irrelevante Zustande bevorzugt 
voneinander. 

Die Zeitinformation ist beispifelsweise in der VPU-Technologie 
nach PACTOl, 02, 13 durch das RDY/ACK Handshake erMltlich. 
Hierzu ist jedoch besbhdefs anzumerken, dass das Hatndshake 
ebenfalls keine relevanten Zustand darstellt, da es lediglich 
die GQltigkeit der Daten signalisiert, wodurch sich wiederum 
die verbleibende relevante Information auf die Existenz gaiti- 
ger Daten reduziert- 

2.2-7 Umqanq mit Zeit 

In vielen Prograiraniersprachen, besonders in sequentiellen wie 
z.B. C, wird eine exakte zeitliche Reihenfolge iiuplizit durch 
die Sprache vorgegeben; bei sequentiellen Prograinmiersprachen 
geschieht dies beispielsweise durch die Reihenfolge der ein- 
zelnen Anweisungen. Sofem dies durch die Programmiersprache 
und/oder den Algorithmus erforderlich ist, wird das Con^ilier- 
verfahren so ausgeftihrt, dass sich die Zeitinformation auf 
Synchronisationsmodelle wie RDY/ACK und/oder REQ/ACK oder ein 
Time-Stanqp-Verfahren nach DS 101 10 530*4 abbilden Idsst;. 

Mit anderen Worten wird die implizite Zeitinformation von se- 
quentiellen Sprachen in ein Handshake Protokoll derart abge- 
bildet, dass das Handshake Protokoll (RDY/ACK-Protokoll) die 
Zeitinformation libertrSgt und insbesondere die Reihenfolge der 
Zuweisungen garantiert. 

Beispielsweise wird die nachfolgende for-Schleife nur dann 
durchlaufen und iteriert, wenn die Variable input stream je 
Durchlauf mit einem RDY quittiert ist. Bleibt RDY aus, wird 
der Schleifendurchlauf bis zum Eintreffen von RDY angehalten. 
while TRUE 
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s := 0 

for i:= 1 to 3 

s s + ihput stream; 

Die Eigenschaft der sequentiellen Sprachen^ nur von der Be- 
feblisverarbeltung gesteuert zu werdeh,. wird somit bel der Com-* 
pillerung mit dem Datenflufiprinzlpf die Verarbeitung durch den 
Datenstrom, bzw. die Existenz von Daten zu steuern verbunden. 
Mit anderen Worten wird ein Befehl tmd/oder eine Anveisung 
(z.B. s :=» s + inputstream;) nur verarbeitet, wenn die Opera- 
tion ausgeffihrt werden kann tmd die Daten verfQgbar sind. 

Bemerkenswert ist, daB dieses Verfahren gewdhnlicherweise zu 
keiner Anderung der Syntax oder Semantik einer Hochsprache 
ftihrt- Es kann also vorhandener Hochsprachencode durch Neucom- 
pilierung problemfrei zur AusfUhrung auf einer VPU gebracht 
werden. 



2,2.8 Laden und Speichem von Daten . 

Ffir die Grundlagen der Load/Store Operationen ist f olgendes 
beaphtlich. 

Die nachfolgenden Adressierungsarten werden unterschiedlich 
behandelt : 

1. exteme Adressierung, also die Datentransfers mit exter- 
nen Baugruppen 

2. interne Adressierung, also die Datentransfers zwischen 
PAESr i.b- zwischen RAM-PAEs und ALO-PAEs 

Desweiteren kann die zeitliche Entkopplung der Datenverarbei- 
txing und dem Laden und Speichem der Daten besondere Beachtung 
finden. 
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Bustransfers warden in interne und externe Transfers zerlegt. 
btl) Externe Lesezugriffe {Load Operation) werden separiert, 
in einer ia5glichen Ausftihrung auch bevorzugt in eine separate 
Konfiguration flbersetzt. Die Daten werden von einem extemen 
Speicher ill einen internen transferiert* 

bt2} Interne Zugriffe werden mit der Datenverarbeitting gekop* 
pelt, d.h. die internen Speicher (Register Operation) werden 
ftir die Datenverarbeitung gelesen, bzw. beschrieben. 

bt3) Externe Schreibzugrif f e (Store Operation) werden sepa- 
riert, in einer bevorzugten mdglichen Ausfuhrung auch in eine 
separate konfiguration ubersetzt. Die Daten werden von einem 
internen Speicher in einen extemen transferiert. 

Wesentlich ist, dass die btl, bt2, btS - also das Laden der 
Daten (Load) r das Verarbeiten der Daten (Datenverarbeitung und 
bt2) und das Schreiben der Daten (bt3) - in unterscheidliche 
Konfigurationen fibersetzt werden k5nnen und diese ggf * zu ei- 
nem unterschiedlichen Zeitpunkt ausgeftthrt werden. 

Das Verfahren soil an djsm nachfolgenden Beispiel verdeutlicht 
werden: 

function example (a, b : integer) -> x : integer 
for i:= 1 to 100 
for j:= 1 to 100 
x[i] := a[il * b[j] 

Die Funktion kann vom Compiler in drei Telle, bzw. Konfigura- 
tionen (subconfig) transfonaiert: 

r 

exampletdload: ladt die Daten von extern (Speicher, Periphe- 
rie, etc.) und schreibt diese in interne Speicher. Interne 
Speicher sind mit r# und dem Namen der ursprtinglichen Variable 
gekennzeichnet . 
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exair^le#process: Entsprlcht der eigentlichen Datenverarbei- 
tung. Diese liest die Daten aus internera Operanden und 
schreibt die Ergebnisse wieder in interne Speicher. 
example#dstore: schreibt die ETrgebnisse aus dem intemen Spei- 
cher nach extern (Speicher/ Peripherie, etc.). 

function exait^le# (a, b : integer) -> x : integer 
subconfig exainple#dload 
for i := 1 to 100 

r#a[i] := a[i] 
for j := 1 to 100 

r#b[jl := b(j] 

siibconfig exampletprocess 
for i :« 1 to 100 
for j:= 1 to 100 

r#xti] :« r#a[il * r#b[j] 

subconfig exan^letdstore 
for i := 1 to 100 
x[il r#x[il 

Ein wesentlicher Effekt des Verfahrens ist, dass anstatt i*j =» 
100 * 100 = 10.000 exteme Zugriffe nur i+j ^ 100 + 100* = 200 
exteme Zugriffe zum Lesen der Operanden ausgeftthxt werden. 
Diese Zugriffe sind zudem noch vollkommen linear, was die 
Transfergeschwindigkeit bei modemen Bussystemen (Burst) 
und/oder Speichem (SDRAM, DDRAM, RAMBUS, etc) erheblich be- 
schlevinigt. 

Die intemen Speicher zugriffe erfolgen parallel, da den Ope- 
randen unterschiedliche Speicher zugewiesen wurden. 
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Zto Schreiben der Ergebnisse sind i » 100 externe Zugriffe 
notwendig^ die ebenfalls wieder linear mit maximaler Perfor- 
mance erfolgen konnen. 

Wehh die Anzahl der Datentransfers vorab nicht bekannt ist 
(z.B. WHILiS-Schleifen) Oder sehr grbfi ist^ kann ein Verfahreii 
verwendet werden, das bei Bedarf durch Untej^Drogrannnaufrufe 
die Operanden nachlSdt bzw. die Ergebnisse nach e^ctem 
schreibt. Dazu konnen in einer bevorzugten AusfQhrung (auch) 
die Zustande der FIFOs abgefragt werden: 'empty' wenn das FIFO 
leer ist, sowie 'full' wenn das FIFO vol! ist. Entsprechend 
der Zustande reagiert der Programmf luB - Zu bemerken ist, dass 
bestiiniate Variablen (z.B. ai, bi, xi) global definiert sind. 
Zu Performanceoptimierung kann ein Scheduler entsprechend der 
bereits beschriebenen Verfahren die Konfigurationen examp- 
le#dloada, example#dloadb bereits vor deia Aufruf von exantp- 
lefprocess bereits ausfClhren, sodass bereits Daten vorgeladen 
sind. Ebenso kann exainple#dstore (n) nach der Terminiemng von 
example#process noch aufgerufen werden um r#x zu leeren. 

subconfig exai[^Ie#dloada(n) 
while !full(r#a) AND ai<»n 
r#a[ai] a[ai] 
ai++ 

subconfig exanplefdloadb (n) 
while !full{r#b) AND bi<=n 
r#btbil :« htbi] 
bi++ 

subconfig exan^leidstore (n) 
while ! empty (r#x) AND xi<«n 
x[xi] := r#x[xi] 
xi++ 
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siibconfig exainple#process 
for i := 1 to n 
for j:= 1 to m 

if CTipty(r#a) then example^idloada (n) 

if en^ty(r#b} then examplefdloadb (m) 

if full(r#x) then example#dstore (hj 

r#x[i] := rfati] * r#btj] 
bj 1 

Die Unterprograznmaufrufe und das Verwalten der globalen Varia- 
blen sind fUr rekonf igurierbare Architekturen vergleichsweise 
aufwendig. Daher kann in einer bevorzugten AusfUhnang die 
nachfolgende Optimierung durchgeftihrt warden, in welcher sSmt- 
liche Konfigurationen weitgehend unabangig ablaufen und nach 
vollstMndiger Abarbeitung terminieren (terminate) . Da die Da- 
ten b[jl mehrfach erforderlich sind, mu£ exan^leidloadb ent- 
sprechend mehrfach durchlaufen werden* Dazu werden beispiels- 
weise zwei Altemativen dargestellt: 

Alternative 1: exazi^lefdloadb texminiert nach jedem Durchlauf 
und wird von exampletprocess fOr jeden Neustart neu konfigu* 
riert. 

Alternative 2: examplefdloadb ISuft unendlich und wird von ex- 
anipletprocess terminiert. 

wahrend • idle • ist eine Konf iguration untatig (wartend) • 

subconf ig examplefdloada (n) 
for i:= 1 to n 
while full(r#a) 

idle 
r»a(i] := ati] 
terminate 



subconf ig examplefdloadb (n) 
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While 1 // ALTEBNATIVE 2 
for i:= 1 to n 
while full{r#b) 

idle 
r#b[i] a[ii 
terminate 
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subconfig exainple#dstore (n) 
for i:= 1 to n 
while empty (r#b) 

idle 
x[il := r#x[ij 
terminate 

siibconfig examplefprocess 
for i 1 to n 
for j:« 1 to m 

while empty (r#a) or empty (r#b} or full{r#x) 
idle 

r#x[i] :« r#a[i] * r#b[j] 
conficT exampleidloadb (n) // ALTERNATIVE 1 
terminate exampleidloadh (n) // ALTEENATIVE 2 
terminate 

Zur Vermeidung von Wartezyklen konnen Konfigurationen auch 
teanniniert werden, sobald sie ihre Aufgabe temporar nicht wel- 
ter er fallen kCnnen. Die entsprechende Konfiguration wird von 
dera rekonfigurierbaren Baustein entfemt, verbleibt jedoch im 
Scheduler. Hierzu wird im Folgenden der Befehl * reenter* ver- 
wendet. Die relevanten Variablen werden vor der Terminierung 
gesichert und bei der wiederholten Konfiguration wiederherge- 
stellt: 



subconfig exanqple#dloada(n) 
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for ai:« 1 to n 

if fuli(r#a) reenter 

rtaiai] := a[ai] 
terminate 

subcpnfig exaihple#dlbadb(n) 
while 1 // ALTERNATIVE 2 
for bi:= 1 to n 

if full(r#b) reenter 
r#fa[bi] := a [hi] 
tenainate 

subconf ig exan^letdstore (n) 
for xi:= 1 to n 

if empty (r#b) reenter 

xtxi] := r#x[xi] 
terminate 

si2bconfig exan^lefprocess 
for i := 1 to n 
for j := 1 to m 

if empty {r#a) or empty (r#b) or full(r.#x) reenter 
r#x[i] :=» r#a[i] * r#b(j] 
config example fdloadb (n) // ALTERNATIVE 1 
terminate exam^>leidloadbln) // ALTERNATIVE 2 
terminate 

2,3 Makros 

Komplexere Funlctionen einer Hochsprache, wie z.B. Schleifen, 
verden typisch durch Makros realisiert. Die Makros verden da- 
bei vom Ccnpiler vorgegeben und zur Obersetzungszeit instanti* 
iert. (vgl. Figur 4). 
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Die Makros sind entweder aus einfachen SprachkonstruJcten der 
Hochsprache oder auf Assemblerlevel alifgebaut. Makros k5hnen 
parametrisiert sein, urn eihe einfaiche Adaption an den beschie-: 
benen' Algorithmus zu ermoglicl/fen. (vgl. Figur 5, 0502). Die 
Makros sind auch vorliegerid einzugliedem. 

2>4 Feedback Loops und Register 

Innerhalb der Abbildung eines Algorithmus in ein kombinatori- 
sches Netz konnen unverzogerte RQckkopplungen entstehen, die 
unkontroiliert schwingen. 

In praktisch iiitplementierten VPO-Technologien gem^fi PACT02. 
wird dies durch einen Aufbau der Fi^ verhindert, bei weichem 
mindestens ein Register zur Entkopplimg, etwa £est in den 
PAEs, definiert ist. 

Generell sind unverz5gerte Rfickkopplungen diirch Graphenanalyse 
des entstandenen kombinatorischen Netzes feststellbar* In die 
Datenpfade, in denen eine unverz5gerte Rtickkopplung besteht, 
werden daraufhin gezielt Register zur Entkopplung eingefUgt. 
Der Compiler kann somit Register- beziehungsweise Speichexmit- 
tel verwalten. 

Durch die Verwendung von Handshake-Protokollen (z.B, RDY/ACK 
gem. 2.2.7) ist die korrekte Fimktion der Berechnung auch 
durch das EinfCLgen von Registem sichergestellt . 

2,5 Prozssormodell / Time Domain Multiplexing (TDM) 
Grundsatzlich besitzt jede praktisch realisierte PAE-Matrix 
lediglich eine endliche Grdfie. Daher mufi im folgenden Schritt 
eine Partitionierung des Algorithmus nach 2.2.5 Abs. 4 a/b in 
eine Mehrzahl von Konfigurationen durchgefUhrt werden, die 
nacheinander in die PAE-Matrix konfiguriert werden. Ziel ist 
typisch, mdglichst viele Datenpakete in dem Netzwerk zu be- 
rechnen, ohne umkonf igurieren zu miissen. 
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Zwischen den Konfigurationen wird eine Zwischenspeicherung 
vorgenommen, wobei der Zwischenspeicher - ahnlich eihes Regi- 
sters bei CPUs - die Daten zwi'Schen den einzelnen. secpientieil 
ausgeftihrten Konfigurationen speichert. 

Somit wird durch das Rekonfigurieren von Konfigurationen, der 
Datenverarbeitung in der PAE-Matrix und der Zwischenspeiche- 
rung in den Speichern ein sequentielles Prozessormodell aufge- 
baut . 

Mit anderen Worten wird in der VPU-Technologie durch die be- 
schriebene Compilierung nicht ein OpCode sequentiell ausge- 
fiihrt, sondem komplexe Konfigurationen. Wdhrend bei CPUs ein 
Opcode typischerweise ein Datenwort bearbeitet, werden in der 
VPO-Technologie eine Mehrzahl von Datenworten (ein Datenpaket) 
von einer Konfiguration bearbeitet. Dadurch steigt die Effizi- 
enz der rekonfigurierbaren Architektur durch ein besseres Ver- 
haitnis zwischen Rekonfigurationsaufwand und Datenverarbei- 
tung. 

In der VPU-Technologie wird zugleich anstatt eines Registers 
ein Speicher verwendet, da nicht Datenworte, sondem Datenpa- 
kete zwischen den Konfigurationen bearbeitet werden. 

Dieser Speicher kann als Pandom-Access Memory, Stack, FIFO 
Oder als beliebige andere Speicherarchitektur ausgestaltet 
sein, wobei typischerweise mit einem FIFO die beste und am 
einfachsten zu realisiernde MSglichkeit gegeben ist. 

Daten werden nunmehr durch die PAE-Matrix, entsprechend des 
konfigurierten Algorithmus, bearbeitet und in einem oder meh- 
reren Speichern gespeichert. Die PAE-Matrix wird nach der Be- 
arbeitung einer Menge von Daten urakonfiguriert und die neue 
Konfiguration entnirarat die Zwischenergebnisse aus dem/den 
Speicher (n) und setzt die Ausfuhrung des Programmes fort. Da- 
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bei kdnnen durchaus auch neue Daten von externen Speichern 
und/oder der Peripherie zuscLtzlich in die Berechnung elnflie- 
Eteh, ebenso kdnnen Ergebnisse an externen Speichern iind/oder 
der Peripherie geschrieben wei^^en* 

Mit anderen Worten ist der typische Ablauf einer Datenvefar- 
beitung das Auslesen von internen RAMs, das Verarbeiten der 
Daten in der Matrix und das Schreiben von Daten in die inter- 
nen Speicher, wobei zur Datenverarbeitung auch beliebige ex- 
terne Quellen oder Ziele ftir Datentransfers zusatzlich oder 
anstelle der internen Speicher verwendet werden kdnnen. 

W3hrend "sequencen"' bei CPUs als das Neuladen eines OpCodes 
definiert ist., wird natih dem Vorstehenden "sequencen" von VPDs 
also als das (Re) konf igurieren von Konfigurationen definiert. 
Dies bedeutet allerdings nicht, d£iB nicht unter bestimoiten Be- 
dingungen Telle des Feldes als Sequenzer im herkdmmlichen Sin- 
ne betrieben werden kbnnten* 

Die Information, wann und/oder wie gesequenzt wird/ d.h. wel- 
che nachste Konf igurat ion konfiguriert werden soil, ist durch 
verschiedene Informationen darstellbar, die einzeln oder kom- 
biniert verwendet werden kSnnen. Z. B. sind folgende Strategic 
en zur Ableitung der Information allein und/oder in Koinbinati- 
on bzw. aiternativ sinnvoll: 

a) diirch den Compiler zur Qbersetzungszeit definiert; 

b) durch das Event-Netzwerk definiert 
{Trigger, DB 197 04 728.9), 

wobei das Eventnetzwerk interne und/oder exteme Zust&nde 
repr£Lsentieren kann; 

c) durch den FUllgrad der Speicher 

(Trigger, DE 197 04 728.9, DE 196 54 846.2-53). 



2.5.1 Einflufl des TDM auf das Prozessormodell 
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Die Partitionierung dea Algorithmus bestizmat entscheidend die 
relevanten Zustande, die in den Speichern zwischen den ver- 
schiedenen Konfigurationen abgelegt werden. Sofern ein Zustand 
iur innerhalb einer Konf iguraW-on relevant ist (lokal relevan- 
ter Zustand), ist es nicht . notwendig, diesen 'zu speichern, was 
vom Compilierverfahren bevorzugt beriicksichtigt wird. 

Zu Zwecken des Debuggings des auszufQhrenden Programmes kann 
es aber sinnvoll sein, diese ZustSnde dennoch zu speichern, um 
dem Debugger einen Zugriff auf diese zu ermdglichen. Auf die 
DE 101 42 904.5 wird verwiesen; diese ist hiennit vollumfang- 
lich zu Offenbarungszwecken eingegliedert . 

Weiterhin kOnnen zusatzlich Zustande relevant werden, wenn ein 
Taskswitch-Mechanlsmus (z.B. durch ein Bet riebs system oder In- 
terruptquellen) verwendet wird und aktuelle ausgefOhrte Konfi- 
gurationen unterbrochen werden, andere Konfigurationen geladen 
werden und/oder zu einem spSteren Zeitpunkt die abgebrochene 
Konfiguration fortgesetzt werden soil. Eine detailliertere Be- 
schreibung folgt im nachfolgenden Abschnitt- 

Ein einfaches Beispiel soli ein Unterscheidungsmerkmal ftir lo- 
kal relevante Zustande aufzeigen: 

a) Bine Verzweigung des Types "if () then ... else ..." paBt 
vollstandig in eine einzige Konfiguration, d.h. beide Da- 
tenpfade (Zweige) sind gemeinsam vollstandig innerhalb der 
Konfiguration abgebildet. Der sich beim Vergleich ergebende 
Zustand ist relevant, jedoch lokal, da er in den nachfol- 
genden Konfigurationen nicht mehr benetigt wird. 

b) Dieselbe Verzweigung ist zu groB, um vollstandig in eine 
einzige Konfiguration zu passen. Mehrere Konfigurationen 
sind notwendig, um die vollstandigen Datenpfade abzubilden. 
In diesem Fall ist der Zustand global relevant und mufi ge- 
speichert und den jeweiligen Oaten zugeordnet werden, da 
die nachfolgenden Konfigurationen bei der Weiterverarbei- 
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tung der Daten den jeweiligen Zustand des Vergleichs beno- 
tigen. 



2,6 Task-Switching 

Bineh zus§tziichen EinfluB auf die Betrachtimg und den Umgang 
mit Zustanden hat der mogliche Einsatz eines Betriebssystemes. 
Betriebssysteme verwenden beispielsweise Task-Scheduler zum 
Verwalten mehrere Auf gaben (Tasks) r um ein Multitasking zur 
Verfiigung zu stellen. 

Task-Scheduler brechen Tasks zu einem bestirnmten . Zeitpunkt ab, 
starten andere Tasks und kehren nach deren Abarbeitung zur 
Welterbearbeitung des abgebrochenen Tasks zurfick. 
Sofem sichergestellt ist, daB eine Konfiguration - die hier 
der Abarbeitung eines Tasks entsprechen kann - nvir nach der 
koxnpletten Abarbeitung - d.h. wenn alle innerhalb dieses Kon- 
figurationszyklusses zu bearbeitende Daten und ZustSnde ge- 
speichert sind - terminiert, k5nnen lokal relevante Zust3nde 
xmgespeichert bleiben. Dieses Verfahren, also das komplette 
abarbeiten einer Konfiguration und der nachfolgende Taskswitch 
ist die bevorzugte Methode fUr den Betrieb von rekonfigurier- 
baren Prozessoren und entspricht im Wesentlichen dem Ablauf in 
einem normalen Prozessor, der auch zunachst die aktuell bear- 
beiteten Instruktionen abarbeitet und dann den Task wechselt. 

Ftlr manche Anwendungen 1st jedoch eine besonders kurze Reakti- 
on auf eine Taskwechselsanforderung erforderlich, z.B. in 
Realtime-Anwendungen. Hier kann es sinnvoll sein Konfiguratio- 
nen vor deren koinpletter Abarbeltung abzubrechen. 
Sofem der Task-Scheduler Konfigurationen vor deren vollstan- 
diger Abarbeitung abbricht, massen lokale Zustande und/oder 
Daten gespeichert werden. Weiterhin ist dies von Vorteil, wenoi 
die Abarbeitungszeit einer Konfiguration nicht vorhergesagt 
werden kann. In Verbindung lait dem bekannten Halteproblem und 
dem Rlsiko, daB eine Konfiguration (z.B. durch einen Fehler) 
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gar nicht texminiert, erscheint dies weiterhin sinnvoll, um 
damit einen Deadlock des gesaniten Systems zu verhindem. 
Daher sind vorliegend^ unter Berflcksichtung von Taskwechseln, 
relevante Zustande auch als s<?lche anzusehen, die far einen 
Taskwechsel urid ein erneutes korreiktes Aufsetzeh der Datenver- 
arbeitung nptwendig sind. 

Bei einem Taskswitch ist somit der Speicher fQr Ergebnisse und 
ggf . auch der Speicher fUr die Operanden zu sichern und zu ei- 
nem spateren Zeitpunkt, also bei der RUckkehr zu diesem Task, 
wieder herzustellen. Dies kann yergleichbar zu den PUSH/POP 
Befehlen xmd Verfahren nach dem Stand der Technik erfolgen. 
Weiterhin ist der Zustand der Datenverarbeitxing zu sichern, 
also der Zeiger auf die zuletzt vollsttodig bearbeiteten Ope-* 
randen. Es sei hier besonders auf PACT18 verwiesen. 



Abhangig von der Optlmierung des Taskswitches gibt es bei- 
spielsweise zwei MOglichkelten: 

a) Die abgebrochene Konfiguration wird neu konfiguriert und 
nur die Operanden werden geladen. Die Datenverarbeitung be- 
ginnt so von neuem, als ob die Bearbeitung der Konfigurati- 
on noch gar nicht begonnen wurde. Mit anderen Worhen werden 
einfach alle Datenberechnungen von vome an. ausgefuhrt, wo- 
bei ggf. Berechnungen bereits zuvor durchgefUhrt wurden. 
piese Moglichkeit ist einfach, aber nicht effizient. 

b) Die abgebrochene Konfiguration wird neu konfiguriert, wobei 
die Operanden und die bereits berechneten Ergebnisse in die 
jeweiligen Speicher geladen werden. Die Datenverarbeitung 
wird bei den Operanden fortgesetzt, die nicht mehr voll- 
standig berechnet. wurden. Dieses Verfahren 1st sehr viel 
effizienter, setzt aber voraus, daa ggf. zusStzllche Zu- 
stande, die wSLhrend der Verarbeltung der Konfiguration ent- 
stehen, relevant werden, etwa wenn zumindest ein Zeiger auf 
die zuletzt vollstSLndig verrechneten Operanden gesichert 
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werden muss, damit bei deren Kachfolgern nach erfolgter 
neuer Konfiguration neu aufgesetzt werden kann. 



2^7 Kontext Switch 

Eine besonders bevbrzugte Variante zur Vierwaltung von televah- 
ten Daten wird durch den nachfolgend beschriebenen Kontext 
Switch zur Verftigung gestellt. Bei TasJc-Wechseln und/oder bei 
der Ausftihrung von Konfigurationen und derem Wechsel (siehe 
beispielsweise Patentanmeldung DE 102 06 653.1, die zu Of f en^ 
barungszwecken vollumfanglich eingegliedert ist) kann es er- 
forderlich sein, Daten oder ZustSnde^ die typischerweise nicht 
zusaznmen mit den Arbeitsdaten in die Speich^r abgelegt werden, 
da sie beispielsweise ledlglich einen Endwert loarkieren, fUr 
eine nachfolgende' Konfiguration zusichern. 

Der erfindungsgemSB bevorzugt impl^entierte Kontext Switch 
wird derart durchgeftihrt, dass eine erste Konfiguration ent- 
femt wird und die zu sichemden Daten in entsprechenden Spei- 
chem (REG) (Speicher, Register, ZMhler, etc) verbleiben. 

Dann kann eine zweite Konf igxiration geladen werden, diese ver- 
bindet die REG in geeigneter Weise und definierter Reihenfolge 
mit elnem oder mehreren globalen Speicher(n). 
Die Konfiguration kann beispielsweise Adressgeneratoren ver- 
wenden, urn auf den/die globalen Speicher zuzugreifen. Es ist 
also nicht erforderlich, vorab jeden einzelnen Speicherplatz 
durch den Conqpiler f estlegen zu lassen und/oder auf als Spei- 
cher ausgestaltete REG zuzugreifen. 

Entsprechend der konf igurierten Verbindung zwischen den REG 
werden die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jewelligen Adres- 
sen von Adressgeneratoren vorgegeben werden. Der Adressgenera- 
tor generiert die Adressen far den/die globalen Speicher (n) 
derart, dass die beschriebenen Speicherbereiche (PUSHAREA) der 
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entfernten ersten Konfiguration eindeutig zugeordnet werden 
kSnnen. 

Es werden somit bevorzugt fur unterschiedliche Konfigurationen 
unterschiedliche AdressenrSum^ vorgesehen. Die Konfiguration 
entspriicht dabei einem POSH gewOhnlicher Prozessofen. 

Danach verwenden andere Konfigurationen die Ressourcen. 

Nun soil die erste Konfiguration wieder gestartet werden. Zu- 
vor wird eine dritte Konfiguration gestartet, die die REG der 
ersten Konfiguration in einer definierten Reihenfolge ndtein- 
ander verbindet. 

Die Konfiguration kann wiederum beispielsweise Adressgenerato-* 
ren verwenden um auf den oder die globalen Speichem zuzugrei- 
fen und/oder um auf als Speicher ausgestaltete REG zuzugrei- 
fen. 

Ein Adressgenerator generiert dabei Adressen bevorzugt derart, 
dass ein korrekter Zugriff auf die der ersten Konfiguration 
zugeordnete POSHAREA erfolgt. Die generierten Adressen und die 
konfigurierte Reihenfolge der REG sind derart, dass die Daten 
der REG in der ursprdnglichen Ordnung aus den Speichem in die 
REG geschrieben werden. Die Konfiguration entspricht einem POP 
gew5hnlicher Prozessoren. 

Nun wird die erste Konfiguration wieder gestartet. 

ZusammengefaBt wird ein Kontext Switch bevorzugt derart durch- 
gefUhrt, dass durch das Laden besonderer Konfigurationen, die 
ahnlich von PUSH/POP bekannter Prozessorarchitekturen arbei- 
ten, die zu sichemden Daten mit einem* globalen Speicher aus- 
getauscht werden. Dieser Datenaustausch Ober globale Speicher 
mittels von Push/Pop-Austauschkonfiguationen wird als beson- 
ders relevant angesehen. 
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Die Funktion soil in einem Beispiel verdeutlicht werden: 

Bine Funktion addiert 2 Zahlenreihen, die L^nge der Reihen ist 

zur Obersetzungszeit nicht bel^nnt, sondern erst zur Laufzeit. 

proc example 

while Klength do 
x[il = a[il + b[i] 
i - i + -1 

Die Funktion wird nun wMhrend ihrer AusfOhrung unterbrochen, 
beispielsweise durch einen Task-Switch, oder well der fQr x 
vorgesehene Speicher voll ist* a,b,x befinden sich zu diesem 
Zeitpunkt erfindungsgemSB in Speichern. i und ggf • length rotis- 
sen jedoch gesichert werden. 

Dazu wird die Konfiguration example terminiert, wobei die Re- 
gisterinhalte erhalten bleiben und eine Konfiguration push ge- 
startet, die i und length aus den Reglstern liest und in einen 
Speicher schreibt. 

proc push 

mem[<push_adr_example>] = i 
push_adr_exampl.e++ 
mem[<push__adr_example>] = length 

Nach der AusfOhrung wird push terminiert und die Registerin*- 
halte kOnnen geldscht werden. 

Andere Konfigurationen werden ausgeftihrt. Nach einiger Zeit 
wird die Konfiguration example wieder gestartet. 
Zuvor wird eine Konfiguration pop gestartet, die die Registe- 
rinhalte wieder aus dem Speicher liest « 

proc pop 

i « mem[<push_adr_exainple>] 
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push_adr__example++ 

length = ineia[<push_adr_exaiaple>] 



Nach der Ausfahrung wird pop Ijrerminiert und die Registerinhal- 
te bleiben besteheii. Die Kbnfiguration example wird wieder ge- 
startet. 



2,8 Alqorithmische Optimierunq 

Durch das beschriebene tJbersetzungsverfahren werden Kontroll- 
struJcturen von algorithmischen Strukturen getrennt, Beispiels- 
weise zerfallt eine Schleife in einen Rumpf (WHILE) und eine 
algorithmische Struldbur (Anweisungen) . 

Die algorithioischen Strukturen lassen sich nunmehr bevorzugt 
optional durch ein zusatzliches, der Trennung nachgeschaltetes 
Werkzeug optinderen, 

Beispielsweise kaim eine nachgeschaltetes Algebra-Software die 
prbgrammierten Algorithmen optinderen und xtdnimieren. Dereurti- 
ge Tools sind z.B. unter Bezeichnungen wie AXIOM, MARBLE, etc. 
bekannt. Durch die Minimierung kann eine schnellere Ausftihrung 
des Algorithmusses imd/oder ein erheblich verringerter Platz- 
bedarf erreicht werden. 

Das Ergebnis der Optimierung wird danach wieder in den Conqpi- 
ler geftlhrt und entsprechend weiterverarbeitet . 
Es soil zudem angemerkt sein, dass modeme Compiler (- 
Frontends) bereits eine Anzahl von Optiioierungen ftir Algo- 
rithemen (auch z.T. algebraische) iiq)lementlert haben, die 
selbstverstandlich im Rahmen des hier beschriebenen Verfahrens 
weiterhin nutzbar sind. 

Es soli ausdrticklich erw^hnt sein, dass die beschriebenen Ver- 
fahren, insbesondere jedoch die Abschnitte 2.2.7 "Umgang mit 
Zeif und 2.3 "Makros" auch auf Compiler nach PACT20 angewen- 
det werden konnen. PACT20 wird diesbezUglich zu Offenbarungs- 
zwecken vollumfSnglich in diese Patentanmeldung einbezogen. 
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3. Anven dbarkeit fiir Prozessoren nach dem Stand der Technik, 
insbesondere nit VLIW-Architektur 

Es soil besonders angemerkt werden, daJB anstatt elher PAE- 
Matrix auch eine Anordnung von arithmetisch logischen Einhei- 
ten nach dem Stand der Technik (ALUs) , wie beispielsweise in 
VLIW-Prozessoren tiblich, und/oder eine Anordnung von komplet- 
ten Prozessoren, wie beispielsweise in Multiprozessorsystenien 
tiblich, yerwendet werden kann. Ein Sonderfall stellt dabei die 
Verwendurig einer einzelnen ALU das, sodaB das Verfahren auch 
ftir normale. CPUs verwendbar ist. 

In der Dissertation [Referenz Dissertation Armin NQckel] wurde 
ein Verfahren entwickelt, das die Obersetzung der WHILE- 
Sprache in semantisch korrekte endliche Automaten ermdglicht. 
Dariiber hinaus kann ein endlicher Automat als "Unterprogramm*' 
verwendet werden und umgekehrt. Dadurch entsteht die M€Jglich- 
keit, eine Konfiguration auf unterschiedliche Implementie- 
rungstechnologien abzubilden, wie z.B. CPUs; symmetrische Mul- 
tiprozessoren; FPGAs; ASICs; VPUs. 

Insbesondere ist es moglich, Teilen einer Applikation die je- 
weils optimal geeignete Hardware zuzuordnen bzw. eine jeweilie 
Eignung zu bestimmen und anhand der mehr odef weniger guten 
Eignung die optimale Hardware zuzuordnen. Dabei sind bevorzugt 
auch ten?)orare Ressourcenverteilungen und -reservierungen er- 
faBbar. Mit anderen Worten wxirde beispielsweise eine Daten- 
fluBstruktur einer DatenfluBarchitektur zugeordnet werden, 
wahrend eine sequentielle Struktur auf einen Sequenzer abge- 
bildet wird, sofem diese vorhanden und/oder verfttgbar sind. 

Die entstehende Problemstellungen der Ressourcenzuweisungen 
fiir die einzelnen Algorithiaen kOnnen z.B. durch einen "Job As- 
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signmenf-AlgorithiKus zur Verwaltung der Zuordnung gel5st wer^ 
den. 



4 > UnpleTnentiermig 

Die Implement iertmg eihes erf indungsgemS^^ Compilers soil von 
eine "normalen'' sequeritieilen Prograinmierisprache ausgehen, al- 
so 2.B. C Oder Pascal. Diese Sprachen weisen die Eigenschaft 
auf, dass durch ihren sequentiellen Charakter eine zeitliche 
Abfolge implizit und JcQnstlich durch die Sprachendeflnition an 
sich generiert wird, 
Beispiel A: 
Zeile 1: i++ 
Zeile 2: a = i * b 
Zeile 3: x « p - a 
Zeile 4: j = i * i 



Durch die Sprachdefinitlon ist fest vorgegeben, dass Zeile 1 
vor Zeile 2 vor Zeile 3 vor Zeile 4 ausgeftihrt wird. Aller- 
dings konnte Zeile 4 auch direkt nach Zeile 1 ausgefOhrt wer- 
den und somit parallel zu Zeile 2 und 3 bearbeitet werden. 



Hit anderen Worten wer den durch . seguentielle Sprachen weitere 
ktlnstliche und nicht algorithmisch bedingte Zustande einge- 
baut. Wichtig ist ledigllch die korrekte zeitliche Abfolge der 
Berechungen in Beispiel A. Zeile 4 darf erst berechnet werden, 
wenn i korrekt def iniert ist^ also nach der Abarbeitung von 
Zeile 1. Auch Zeile 2 darf erst nach der korrekten Definition 
von i (also nach der Abarbeitung von Zeile 1) verarbeitet wer- 
den. Zeile 3 benStigt die Brgebnisse von Zeile 2 (die Variable 
a) und darf daher erst nach derer korrekten Definition berech- 
net werden. Somit ergibt sich eine DatenabhSngigkeit aber kei- 
ne besonderen ZustSnde. 



Anhand der DatenabhSngigkeiten der Variable a in Zeile 2 und 3 
(Zeile 3 verwendet a als Operand, a ist das Ergebnis von Zeile 
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2) kann automatisch durch den Compiler folgende Transformation 
zxir Reprasentation der Parallelisier- bzw. Vektorisierbarkeit 
(ParVec-Transfonnation) durchgeftihrt warden: 

Zeile 2: VEC{a = i * b; 
Zeile 3: x = p - a} 

VEC bedeutet, dass jeder durch getrennte Ausdruck nachein- 
ander abgearbeitet wird, wobei die Ausdrucke iimerhalb der ge- 
schweiften Klammern grundsatzlich gepipelinet. werden kannen. 
Bevorzugt miissen sSmtliche Berechnungen am Ende von VEC{} 
durchgefGhrt und abgeschlossen sein, damit die Datenverarbei- 
tung hinter VEC fortgesetzt wird. 

Besser wird in einer intemen Reprclsentation der Datenstruktu- 
ren im Compiler die beiden Berechnungen als ein Vektor mar- 
kiert: 

VEC{a==i*b; x=p-q} 

Zeile 4 ergibt einen einfachen Vektor: 
VEC{j = i*i} 

Da sich Zeile 4 gleichzeitig zu Zeile 2 und 3 berechnen l^sst 
kann die Parallelitat folgendermassen ausgedrackt werden: 

PAR{{VEC{a=i*b; x=p-a};VEC{ j=i*i} } 

PAR bedeutet, dass jeder durch getrennte Ausdruck zeit- 

gleich abgearbeitet werden kann. Bevorzugt mQssen s&atliche 
Berechnungen am Ende von PAR{} durchgefUhrt und abgeschlossen 
sein, damit die Datenverarbeitung hinter PAR fortgesetzt wird. 



Wird Zeile 1 mit einbezogen, ergibt sich: 
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Da VEC{j=i*i} ein VeJctor rait nUr einem Element darstellt^ kann 
auch wir folgt geschrieben werden: 

VEC{i++; PAR{{VEC{a=i*b; x=p-a) } { } } 



Ein weiteres Beispiel zeigt einen echten Zustand. 

Beispiel B: 

Zeile 1: i++ 

Zeile 2: a i * b 

Zeile 3: if a < 100 { 

Zeile 4: x = p - a 

Zeile 5: } else { 

Zeile 6: j « i * i } 

Jetzt kann Zeile 6 nur noch nach der Berechnung von Zeile 2 
und Zeile 3 ausgefiihrt werden. Die Berechnung von Zeile 4 und 
6 findet alternativ statt. Also ist der Zustand von Zeile 3 
far die weitere Datenverarbeitung relevant (relevanter Zu- 
stand) • 

Bedingte ZustSnde k5nnen bei einer Transformation durch IF 
ausgedrtickt werden: 

Zeile 1-2: VEC{i++; a«i*b} 

Zeile 3: IF{{a<100}{zeile4}{zeile6}} 

Zeile 4: VEC{x=^p-a) 

Zeile 6: VEC{j==i*i) , 



Zusamraengef aBt ergibt das 

VEC{i++; a=i*b? IF{ {a<100) {VEClx=p-a} } {VEC{ j=i*i} } } } 
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Weitere relevante Zustande warden durch Schleifen erzeugt: 
Beispiel C: 

Zeile 1: for (i = 1^ i < 100, i++) 
Zeile 2: a=a*i 
Zeile 3: q P / a 

Zeile 3 darf erst ausgefuhrt werden, nachdem die Schleife ter- 
miniert ist. Also bestehen bei bedingten SprOngen relevante 
Zustande. 

Eine erste Transformation der Schleife ergibt: 

Zeile 1: i=l; 

Zeile 2: loop: if i >« 100 then exit 

Zeile 3: a = a * i 

Zeile 4: i++ 

Zeile 5: jump loop 

Zeile 6: exit: q = p / a 

Zeile 3 und 4 kdnnen parallel berechnet werden, da Zeile 4 
nicht vom Ergebnis von Zeile 3 abhangt:* 



PAR{(a=a*i){i++}} 



Zeile 5 ergibt einen Vektor mit dem generierten PAR^ da erst 
nach vollstandiger Berechnung der Werte wieder in die Schleife 
gesprungen werden darf (hier liegt also eine zeitliche Abhan- 
gigkeit vor) . 



VEC{PAR{{a=a*i}{i++)); jump loop} 
Somit ergibt sich tQr die Bedingung: 

loop: IF{{i>=100}{jump exit}{VEC{PAR{{a=a*i}{i++}}; jump 
loop})} 
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Die Zeile 1 ist ein Vektor mit der Bedingung, da diese vor der 
Bedingung ausgefOhrt werden muss (IF verwendet i als Operand, 
i ist das Ergebnis von Zeile 1) . 

Zeile 6 ist wiederum ein VektcTr mit der Bedingung, da a als 
Operand verwendet wird und a das Ergebnis der Bedingung ist. 

Somit ergibt sich (in Qbersichtlicher Schreibweise) : 
VEC{ 

i++; 

loop: IF{ 

(i>«l"00> 
{jump exit} 
{VEC{ 
PAR{ 

{a=a*i} 
{i++} 

}; 

jump loop 
} 

} 

}; 

exit: q=p/a 

) 

Die Inhalte von VEC{} und PAR {) Ic5nneh als rein kbxnbinatbri- 
sche Netze betrachtet werden. 

Bevorzugt wird VEC und PAR ale Petri-Netz ausgestaltet, urn wie 
bevorzugt die Weiterverarbeitung nach koii?>letter Verarbeitung 
der jeweilgen Inhalte zu steuem. 

Durch die m5gliche Betrachtung von VEC und PAR als rein kombi- 
natorisches Metz entsteht die Notwendigkeit den Schleifenzu- 
stand zu sichern. D^h. in diesem Fall ist es tatsSchlich not- 
wendig einen endlichen Automaten zu schaffen. 
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Die Anweisung REG{ } speichert dazu Variablen in einem Regi- 
ster. Somit entsteht durch die Verwendung der kombinatorischen 
Netze VEC und PAC in Verbindung mit dem Register REG ein end- 
licher Automat, der exakt ents|)rechend des Algorithmus aufge- 
baut ist: 



VEC{ 

i++; 

loop: IF{ 

{i>-100} 
{jump exit) 
{VEC{ 

PAR{ 

{a-a*i} 
. {i++} 

}; 

REG{a/i} 
jump loop 
} 

} 

}; 

exit: q=p/a 

} . 

Es soil besonders darauf hingewiesen werden^ dass' lii der VPO 
Technologie des Anmelders (vgl. PACT21) Bin- und/oder Aus- 
gangsregister an den PAEs vorgesehen sind und die zeitliche 
Korrektheit und die VerfUgbarkeit von Daten durch ein inte- 
griertes Handshake- Protokoll (EU)Y/ACK) sichergestellt 1st. In- 
soweit wird die Forderung bevorzugt beim Verlassen von VEC{} 
Oder PAR{} deren interne Datenverarbeitung abgeschlossen zu 
haben automatisch far alle nachfolgend verwendeten Veriablen 
erfiillt (ware die Datenverarbeitung nicht beendet, wOrden 
nachfolgende Berechnungsschritte auf die Beendigung und das 
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Eintreffen der Daten wart en) . Durch die integrierten Register 
sind auch schwingende Rtickkopplungen ausgeschlossen. 

Insoweit ist nachfolgender Tern fiir diese Technologie korreict: 
VEC{PAR{{a=a*i}(i++}}; jun^ loop} 

Fiir andere Technologien, die die o.g. Ausgestaltungen nicht 
Oder nur teilweise aufweisen, sollte der Term folgenderinassen 
formuliert werden: 

VEC{PAR{{a=a*i}{i++}l; REG{a;i}; jump loop} 

Es soli darauf hingewleseh werden, dass diese Fonci auf" jedezi 
Fall auch in der VPU-Technologie des Anmelders zu einer kor- 
rekten und optimalen Abblldung des Algorithmus auf den rekon- 
figurierbaren Prozessor fOhrt. 

REG kann innerhalb der kombinatorischen Netze VEC und PAR ver- 
wendet werden. Streng betrachtet verlieren dadurch VEC und PAR 
die Eigenschaft der kombinatorischen Netze. Abstrakt kann je- 
doch REG als ein komplexes Element (REG-Element) eines kombi- 
natorischen Netzes betrachtet werden, dem eine eigene Abarbei- 
tungszeit zugrunde liegt- Die . Bearbeitung der nachfolgenden 
Elemente wird vom der Beendigung der Berechnung des REG- 
Elementes abhSngig gemacht. 

In dem Bewusstsein dieser begrif flichen Ungenauigkeit wird ei- 
ne Verwendung von REG innerhalb von VEC und PAR im Weiteren 
zugelassen und ist insbesondere auch notwendig. 

Wie bereits vorstehend erwShnt, ist die Verwendung von REG ty- 
pischerweise innerhalb einer Konfiguration einer VPU des An- 
melders nicht er£orderlich, sondern explizit immer nur dann, 
wenn die Berechnungsergebnisse einer Konfiguration abgespei- 
chert werden, sodass REG ein diesem Anwendungsfall tatsachlich 
dem expliziten Register eines endlichen Automaten entspricht. 
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Neben der Synthese von endlichen Automaten fiir Schleifen, sind 
insbesondere in einem weiteren Fall endliche Automaten erfbir- 
derlich: 

1st ein Algorlthmus zu groB, lim komplett innerhalb der PAEs 
eines rekbnfigurierbareri Prozessbrs abgearbeitet izii werden/ 
muB er in mehrere Teilalgorithmen zerlegt werden. Jeder Tei- 
lalgorithmus stellt eine Konf iguration ftir den rekonfigurier- 
baren Prozessor dar. Nacheinander, also sequentiell, werden 
die Teilalgorithmen auf den Prozessor konfiguriert, wobei die 
Ergebnisse der jeweils vorhergehenden Kon£iguration(en) ftir 
die jeweils neue Konfiguration als Operanden dienen. 

Mit anderen Worten entsteht durch die Rekonfiguration ein end- 
licher Automat , der zu einem Zeitpunkt t Daten bearbeitet imd 
speichert und zu einem Zeitpunkt t+l/ mdglicherweise nach ei- 
ner Konfiguration, die gespeicherten Dateh ggf • anders verar- 
beitet und wieder speichert. Wesentlich ist, dass t nicht im 
klassischen Sinn durch Takte oder Befehle definiert wird, son- 
dem durch Konf igxirationen* Hierzu sein besonders die Presen- 
tation Prozessormodell {PACT/ Oktober 2000, San Jose) referen- 
ziert, 

Mit noch anderen Worten besteht eine Konf iguration aus einem 
kombinatorischen Netz aus VEC und/oder PAR, dessen Ergebnisse 
gespeichert werden (REG), urn in der nSchsten Konfiguration 
weiterverwendet zu werden: 

Konfiguration 1 : VEC{Operands; {VEC | PAR} ;REG{Resultsl } } 
Konfiguration 2: VEC{Re3ultsl;{VEC|PAR};REG{Results2}) 
• • • 

Zum einfacheren VerstSndnis haben die obigen Beispiels und Be- 
schreibungen die Konstrukte VEC, PAR und REG in der Hochspra- 
chen eingeftihrt und diese dadurch strukturiert . Typischerweise 



/ 
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XMid bevorzugt wird diese Strukturierung erst aber auf der Ebe-* 
ne der Zwischensprache (siehe Principles of Compiler Design 
(Red Dragon)/ Aho, Sethis Ollmann) eingefiihrt. 
Es soli besonders darauf hingefwiesen werden, dass die Struktu- 
rierung von Algorithmen mit VEC, PAR und REG typischerweise 
volikommen automatisch durch den Compiler durch Methoden wie 
z.B. Graphenanalyse durchfiihrbar ist. 

Insbesondere ist es aber auch denkbar und teilweise von Vor- 
teil dem Programmierer selbst die StrukturierungsmSglichkeit 
in der Hochsprache dadurch zu ermoglichen/ dass VEC, PAR und 
REG wie oben aufgezeigt direkt in der Hochsprache beschreibbar 
sind. 



Generienmg 

Die automatische Erstellung von VEC, PAR und REG kann auf un- 
terschiedlichen Ebenen einen Compilierungsvorganges durchge- 
ftihrt werden. Die zunachst einleuchtendste ist wahrend eines 
PrSprozessor-Durchlaufes auf Basis des Source-Codes wie in den 
vorigen Beispielen beschrieben. Fiir die weitere Compilierung 
ist danach allerdings ein speziell angepasster Compiler erfor- 
derlich. 

Ein weiterer Aspekt ist, dass Con^jiler zumeist autoniatische 
Optimierungen von Code vomehmen (z.B. in Schleifen) . Sine ef- 
fiziente Zerlegung des Codes ist daher erst nach den Optimie- 
rungslaufen sinnvoll, insbesondere wenn Compiler (wie z.B. 
SOIF, Universitat Stanford) bereits den Code ftlr Parallelisi- 
serung und/oder Vectorisierung hin optimieren. 

Die daher besonders bevorzugte Methode ist die Einbindung der 
Analysen in das Backend eines Conqpilers. Das Backend Cbersetzt 
eine conqpilerinteme Datenstacuktur auf die Befehle eines Ziel- 
prozessors. 
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Als compilerinterne Datenstrukturen werden zumeist Zeiger- 
strukturen wie DAGs/GAGs, Trees oder 3-Adress-Codes verwendet 

(siehe Principles of Compiler .Design (Red Dragon), Aho, Sethi, 
Dllmann) . Teilweise werden auch Stack-Machine-Cddes verwendet 

(siehe Compiler selbstgeschneidert, C'T 1986 1-5) • Da die Da-r 
tenformate prinzipiell Equivalent sind und ineinander trans- 
formiert werden k5nnen, setzt die erfindungsgemSB bevorzugte 
Methode auf der Weiterverarbeitung von Graphen, wie bevorzugt 
Trees ^ auf. 

Datenabh^gikeiten und ndgliche Parallelitaten entsprechend 
dem vorstehend beschriebenen Verf ahren sind iimerhalb von 
Trees einfach auf Basis der Struktur automatisch zu erkennen. 
Hierzu konnen beispielsweise bekannte und etablierte Verfahren 
der Graphenanalyse eingesetzt werden* Alternativ oder optional 
kann durch entsprechend adaptierte Parsingmethoden ein Algo- 
rithmus auf Datenabhangikeiten, Schleifen, Sprdnge etc. hin 
untersucht werden. Dabei kann ein Verfahren ahnlich dem der 
Auswertimg von AusdrQcken in Compilem verwendet werden. 

Abbildonq 

Die weitere Transformation des Algorithmus ist nunmehr stark 
von der Zielarchltektur abhanglg. Beispielsweise bletet ciie 
Prozessorarchitektur des Anmelders (VPU, XPP) automatische Da- 
tensynchronisation In Hardware. Das bedeutet, dass die korrek- 
te zeitliche Abfolge von DatenabhSngigkeiten automatisch in 
der Hardware gehandhabt wird. Andere Architekturen benOtlgen 
zum Tell zusStzllch die Synthese geeigneter Zustandsmaschinen 
fflr die Steuerung es Datentransf ers . 

Besonders inter essant ist die Handhabung bedingter Spriinge. 
Beispielswiese stellt die Prozessorarchitektur des Anmelders 
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mehrere Mechanismen zu derer flbbildung und Ausfahrung zur Ver- 
fiigung: 

1. Rekonfiguration des Prozessors oder Teilen des Prozessors 
durch eine tibergeordnete KonfaTgurationseinheit (vgl. Patentan- 
melduiig(en) PACTOl, 04, 05, 10/13, 17) 

2. Auswalzen der Funktion in das Array aus PAEs (vgl. Pa- 
tentanmeldung PACT08), dabei warden z.B. beide maglichen Zwei- 
ge eines Vergleiches zugleich auf das Array abgebildet, 

3. Wave Rekonfiguration nach Patentanmeldung (en) PACT08, 13, 
17), dabei wird den unterschiedlich zu bearbeitenden Daten ein 
Token mitgegeben, das die jeweils gaitige Konfiguration wahlt. 

Eis soli erwahnt sein, dass der Mechanlsmus 1 der allgemein ty- 
pisch anzuwendende Fall ist. Der Mechanismus 2 ist bereits bei 
den meisten Technologien sehr aufwendig oder gar nicht in^le- 
mentierbar und der Fall 3 ist bislang nur aus der VPU- 
Technologle des Anmelders bekannt. 

Die jeweils zu wahlende AusfUhinmgsmethode hangt von der Kom- 
plexitst des Algorithmus, dem erforderlichen Datendurchsatz 
(Performance) und der exakten Ausgestaltung des Zielprozessors 
ab (z.B. Anzahl der PAEs). 
Beispiele : 

Ein einfacher Vergleich soil fblgendes Berechnen: 
if i < 0 then a«a*(-i) else a«a*i 

Eine Rekonfiguration des Prozessors (Mechanismus 1) je nach 
Ergebnis des Vergleichs scheint wenig slnnvoll zu sedLn. 
Das Auswalzen beider Zweige in das Array (Mechanismus 2) ist 
Gnmdsatzlich moglich, Je nach Ergebnis des Vergleichs werden 
entweder die a«a*(-i) oder a=:a*i berechnenden PAEs angesteuert 
(vgl. PACT08). 

Besonders platzeffizient ist das Oberlagern der beiden Berech- 
nungen (Mechanismus 3) , wodurch nach dem Vergleich unabhangig 
vom Ergebnis dieselbe(n) PAEs die Daten weiterverarbeiten, die . 



wo 03/017095 PCr/EP02n0065 

44 

Daten aber mit einem Token versehen sind, das sodann in AbhSn- 
gigkeit vom Vergleich lokal in den jeweils nachfolgenden die 
Daten verarbeitenden PAEs entweder die Funktion a=a*(-i) oder 
a«a*i auswahlt. (vgl. PACT08, 13, 17). 

Nach Mechahismus 1 entsteht ein global relevanter Zustand, da 
die koniplette folgende Konfiguration davon abhangig ist. 

Nach Mechanisznus 2 und 3 entstehen nur ein lokal relevanter 
Zusftand/ da dieser tlber die Berechnung hinaus - die vollstan- 
dig ixnplementiert ist - nicht mehr benOtigt wird. 

Mit anderen Worten kann die lokale oder globale Relevanz von 
ZustSnden auch von der gewthlten Abbildiing auf die Prozessor- 
architektur abhangen. 

Ein Zustand der Ober eine Konfiguration hinaus und somit Qber 
das kombinatorische Netz des eine Konfiguration reprasentie- 
renden endlichen Automaten hinaus relevant ist {also von nach- 
folgenden endlichen Automaten benotigt wird) , kann grundsatz- 
lich als global betrachtet werden. Es soil nochmals auf die 
verwendete diffuse Terminologie des Begriffes kombinatorisches 
Netz hingewiesen werden. 

Sefehlsmodell des entstandenen Prozessors 

Entsprechend der vorliegenden Brfindung entsteht ein Prozes- 
sormodell fiir rekonfigurierbare Prozessoren, das alle wesent- 
lichen Befehle untfafit: 

Arithmetisch/logische Befehle werden direkt in das kombinato- 
rische Netz abgebildet. 

Sprxinge (Jump/Call) werden entweder direkt in das kombinatori- 
sche Netz ausgewalzt oder durch Rekonfiguration realisiert. 
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Bedinqunq und Kontrollfluflbefehle (if ^ etc) werden entweder im 
kombinatorischen Netz vollstSndig aufgelost und. bearbeitet 
Oder an eine libergeordnete Konfigurationseinheit weitergelei- 
tet, die sodazm entsprechend dfes entstandenen Status eine Re- 
konfiguratioh durchftihrt. 

Load/Store-Operationeii werdeh bsvorziigt ±n separate Konf igiifa- 
tionen abgebildet und durch Adressgeneratoren Shnlich den be- 
kannten OMR's realisiert, die inteimen Speicher (REG{}) mit- 
tels Adressgeneratoren in exteme Speicher schreiben oder die- 
se von extemen Speichem und/oder Peripherie laden. Sie k6n- 
nen aber. auch zusammen mit der datenverarbeitenden Konf igura- 
tion konfiguriert sein und arbeiten. 

Reqistef-Move-Operationen werden im kombinatorischen Netz 
durch Busse zwischen den internen Speichern (RE6{}) reali- 
siert. 

Push/Pop-Operationen werden durch separate Konfigurationen 
realisiert, die ggf . bestimmte interne Register im kombinato- 
rischen Netz und/oder die internen Speicher (REGIl) mittels 
Adressgeneratoren in exteme Speicher schreiben oder aus ex- 
temen Speichern lesen und die bevorzugt vor oder nach den ei- 
gentlichen datenverarbeitenden Konfigurationen ausgefOhrt wer- 
den. 

5. Beschrf^lbnnq der Figmren 

Die nachfolgenden Figuren zeigen Implementierungs- und Ausge- 
staltungsbeispiele des Conpilers- 

Figur la zeigt den Aufbau eines gewOhnlichen endlichen Automa- 
ten^ bei welchem ein kombinatorisches Netz (0101) mit einem 
Register (0102) verknUpft ist. Daten kannen direkt an 0101 
(0103) und 0102 (0104) gefiihrt werden. Durch eine Ruckkopplung 
(0105) des Registers auf das kombinatorische Netz ist die Ver- 
arbeitung eines Zustandes in Abhangigkeit des/der vorhergehen- 
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den Zustande moglich. Die Verarbeitungsergebnisse werden durch 
0106 dargestellt. 

Figur lb zeigt eine ReprSsentartion des ehdlichen Automaten 
durch eine rekonfigurierbare Architefctur nach PACTOl und 
PACT04 (PACT04 ; Fig . 12-15) . Das kombiriatdrisch^n Net z au5 . Fi- : 
gur la (0101) wird durch eine Anordnung von PAEs 0107 ersetzt 
(0101b). Das Register (0102) wird durch einen Speicher (0102b) 
ausgefuhrt, der mehrere Zyklen speichem kann. Die Ritickkopp- 
lung gemaa 0105 erfolgt durch 0105b. Die Eingange (0103b bzw... 
0104b) sind Equivalent 0103 bzw 0104. Der direkte Zugriff auf 
0102b kann ggf . durch einen Bus durch das Array 0101b reali- 
siert werden. Der Ausgang 0106b ist wiederma Equivalent 0106. 



Figur 2 zeigt die Abbildung eines endlichen Automaten auf eine 
rekonfigurierbare Architektur. 0201 (x) reprasentieren das kom- 
binatorische Netz (das entsprechend Figur lb als PAEs ausge- 
staltet sein kann) . Es existieren ein oder mehrere Speicher 
far Operanden (0202) und ein oder mehrere Speicher ftlr Ergeb- 
nisse (0203) . ZusEtzliche Daten £in-/AusgEnge grem. 0103b, 
0104b, 0106b) sind der Einfachh^it halber nicht dargestellt. 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204, 0205). 

Die Operanden- und Ergebnis speicher (0202, 0203) sind physika- 
lisch Oder virtuell derart miteinander verkoppelt, daft bei- 
spielsweise die Ergebnisse einer Funktion bzw. einer Opera- 
tion einer anderen als Operanden dienen konnen und/oder sowphl 
Ergebnisse als auch neu zugeftihrte Operanden einer Funktion 
einer anderen als Operanden dienen k6nnen. Eine derartige 
Kopplung kann beispielsweise durch Bussysteme hergestellt wer- 
den Oder durch eine (Re) Konf iguration durch welche die Funkti- 
on und Vernetzung der Speicher mit den 0201 neu konfiguriert 
wird. 
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Piguir 3 zeigt verschiedene Aspekte zum Umgang mit Variablen. 
In Fignr 3a zeigen 0301, 0302, 0303 verschiedene Stufen der 
Berechnung. Diese Stufen kSnneh rein kombinatorisch oder auch 
tlber Register voneinander getjj^nnt sein. fl, f2, f3 sind Funk- 
tionen, xl ist elhe Variable gemaB Patentbeschreibung. 
Figttr 3b zeigt die Verwendung einer Variablen xl in der Funk- . 
tion xl := xl + 1. 

Pigur 3c zeigt das Verhalten eines endlichen Automaten zur Be- 
rechnung von xl := xl + 1 innerhalb einer Konfiguration; In 
der. nachsten Konfiguration sind. 0306 und 0304 zu vertauschen 
um einen vollstandigen endlichen Automaten zu erhalten. 03O5 
reiprasentiert die Adressgeneratoren fiir die Speicher 0304 und 
0306. 



Figur 4 zeigt Implement ienmgen von Schleifen. Die schraffier- 
ten Module konnen durch Makros generiert warden (0420, 0421) . 
0421 kann auch durch Analyse des Graphen auf unverzSgerte 
Rtickkopplungeh eingefugt werden. 

Figor 4a zeigt die Implementierung einer einfachen Schleife 
der Art 
WHILE TRUE DO 

xl :» xl + 1; 

Im Kern der Schleife liegt dear zahler +1 (0401) . 0402 ist ein 
Multiplexer, der zu Beginn den Startwert von xl (0403) auf 
0401 fahrt und sodann bei jeder Iteration die Rflckkopplxing 
(0404a, 0404b) bewirkt. In die Rtickkopplung ist ein Register 
(vgl. REG{)) (0405) eingesetzt, um eine unverzagerte xind damit 
unkontrollierte Rilckkopplung des Ausgangs von 0401 auf dessen 
Eingang zu verhindern. 0405 wird mit dem Arbeitstakt der VPU 
getaktet .und bestimmt damit die Anzahl der Iterationen pro 
Zeit. Der jeweilige zahlerstand w§re an 0404a oder 0404b ab- 
greifbar. Je nach Definition der Hochsprache terminiert die 
Schleife jedoch nicht. Beispielsweise ware in einer HDL (nach 
dem Stand der Technik (z.B* VHDL, Verilog) das Signal auf 0404 
nutzbar, wHhrend es in einer sequent iellen Programmiersprache 
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(z.B. C) 0404 nicht nutzbar ist, da die Schleife nicht tenai- 
niert und somit keinen Exit-Wert liefert. 

Der Multiplexer 0402 realisiert ein Makro, das aus dem Schlei- 
fenkonstrukt entstanden ist. Pks Makro wird durch die Oberset- 
ziirig von WHILE instant iiert . 

Das Register 0405 ist entweder ebenfalls Teil des Maicros oder 
wird entsprechend einer Graphenanalyse nach dem Stand der 
Technik exakt dann und dort eingefttgt/ wo eine unverzCgerte 
RUckkopplung existiert, um so die Schwingneigung auszuschal- 
ten- 

Figur 4b zeigt den Aufbau einer echten Schleife der Art 
WHILE xl < 10 DO 
xl ;= xl + 1; 

Der Aufbau entspricht im Kern der Figur 4a, weshalb dieselben 
Referenzen verwendet wurden. 

Zusatzlich ist eine Schaltung dargestellt, die die Gaitigkeit 
des Ergebnisses kontrolliert (0410) und das Signal von 0404a 
nur dann an die nachfolgenden Funktionen (0411) weiterleitet, 
wenn das Abbruchkriterium der Schleife erreicht ist. Das Ab- 
bruchkriterium wird durch den Vergleich xl < 10 festgestellt 
(Vergleichsstufe 0412) . Als Ergebnis des Vergleiches wird das 
betreffende Statusflag (0413) an ein MultipXiziermittel 0402 
zur Steuerung der Schleife und die Funktionen 0411 zur Kon- 
trolle der ErgebnisweiterfOhrung geleitet. Das Statusflag 0413 
kann beispielsweise durch Trigger gernkft DE 197 04 728.9 imple- 
mentiert sein. Ebenfalls kann das Status flagmitt el 0413 an ei- 
ne CT gesendet werden, die daraufhin die Terminierung der 
Schleife erkennt und eine Rekonfiguration durchftlhrt. 

Figur 5a zeigt die iterative Berechnung von 
FOR i:«l TO 10 

xl xl * xl; 

Im wesentlichen entspricht die Grundfunktion Figur 4b, weshalb 
die Referenzen Obemoinmen wurden. Der Funktionsblock 0501 be- 
rechnet die Multiplikation. Die FOR-Schleife. wird durch eine 
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weitere Schleife entsprechend Figur 4b implementiert und ist 
lediglich durch Block 0503 angedeutet- Blocic 0503 liefert den 
Status des Vergleiches au£ das Abbruchkriterium. Der Status 
wird direict zur Ansteuerung d^ Iteration verwendet, wodurch 
das Mittel 0412 (dargestellt durch 6502) weitgehenid entfailt. 

Fignr 5b zeigt das Auswalzen der Berechnung von 
FOR TO 10 

xl :« xl * xl; 

Da die Anzahl der Iterationen zur Obersetzungszeit exakt be- 
kannt ist, kann die Berechnung in eine Folge von i Multipli- 
zierern (0510) abgebildet werden. 



Figur 6 zeigt die Ausfiihrung einer WHILE-Schleife gem. Figur 
4b tiber mehrere Konfigurationen . Hier ist der Zustand der 
Schleife (0601) ein relevsuiter Zustand, da dieser die Funktion 
in den nachfolgenden Konfigurationen mafigeblich beeinfluBt. 
Die Berechnung erstreckt sich Ober 4 Konfigurationen (0602, 

0603, 0604, 0605) . Zwischen den Konfigurationen werden die Da- 
ten in Speichem (vgl. RE6{}) abgelegt (0606, 0607). 0607 er- 
setzt dabei ebenfalls 0405. 

Als ein Rekonfigurationskriterium kann der Fdllstand der Spei- 
Cher dienen, angedeutet tiber 0606, 0607: Speicher voll/leer 
und/oder 0601, das den Abbruch der Schleife anzeigt, Mit ande- 
ren Worten werden durch den Ftillstand der Speicher Trigger ge- 
neriert (vgl. PACTOl, PACT05, PACT08, PACTIO), die an die Kon- 
figurationseinheit gesendet werden und eine Rekonfiguration 
auslosen. Auch der Zustand der Schleife (0601) kann an die CT 
gesendet werden. Daraufhin kann die CT bei Erreichen des Ab- 
bruchkriteriums die nachfolgenden Algorithmen konf igurieren, 
bzw* ggf * zunSchst die restlichen Telle der Schleife (0603, 

0604, 0605) abarbeiten und danach die nachfolgenden Konfigura- 
tionen laden. 
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6, Parailelisierbarkeit: 

Figur 6 zeigt potentielle Grei]ften der Parailelisierbarkeit 
auf . 

Sof em die Berechnung der Operanden unabhSngig von der Rflck- 
kopplxing 0608 ist, kann die Schleife blocJcweiser d«h. jevreils 
durch Fallen der Speicher 0606/0607 berechnet werden. Damit 
wird ein hoher Grad an Farallelitat erreicht. 

Sofern die Berechnung eines Operanden abhangig von dem Ergeb- 
nis der vorherigen Berechnung ist, also eine Riickkopplung oder 
dergleichen 0608 in die Berechnung einflieBt, wird das Verfah- 
ren ineffizienter, da jeweils nur ein Operand innerhalb der 
Schleife berechnet werden kann. 

1st der nutzbare ILP (Instruktionslevel Parallelismus) inner- 
halb der Schleife hoch und die Zeit far die Rekonf iguration 
nieder (vgl. PACT02, PACT04, PACT13, PACT17), kann eine auf 
PAEs ausgewalzte Berechnung auf einer VPU weiterhin eff izient 
sein. 

1st dies nicht der Fall, ist es sinnvoll, die Schleife auf si- 
ne sequentielle Architektur (vom PA separater Prozessor oder 
Implementierung innerhalb des PA entsprechend DE 196 51 075.9- 
53, DB 196 54 846.2-53 und insbesondere DE 199 26 538.0 (Fig. 
5r 11/ 16, 17, 23, 30, 31, 33)) abzubilden. 

Die Analyse der Berechnungszeiten kann entweder im Compiler 
zur Obersetzungszeit gemafi dem nachfolgenden Abschnitt erfol- 
gen und/oder empirisch zu der oder einer Laufzeit gemessen 
werden, urn eine nachtragliche Optimierung herbeizufahren, was 
zu einem lernfahigen, insbesondere selbstlemenden Compiler 
fOhrt. 
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Ftir die Erfindung sind Analyse- und Parallelisierungsverfahren 
von Bedeutung. 

Verschiedene Verf ahren nach deta Stand der Technlk stehen fur 
die Analyse und Diirchf tlhrtihg der Pafalleli dierung zur Verf il- 
gung. 

Bin bevorzugtes Verf ahren soli im Folgenden beschrieben wer- 
den. 

Abzubildende Funktionen werden durch Graphen dargestellt (vgl. 
PAGT13; DE 199 26 538.0), wobei eine Applikatlon aus beliebig 
vielen unterschiedlichen Funktionen zusammengesetzt sein kann. 
Die Graphen werden auf die in ihnen \ enthaltehis Farallelitat 
untersucht, wobei vorab samtliche Methoden der Optimieaning zum 
Einsatz koiratien kSnnen. 

Beispielsweise sollen folgende Untersuchungen durchgefuhrt 
werden: 

6.0.1 ILP (Instruction Level Parallelism) 

ILP driickt aus,. welche Befehle zisitgleich ausgeftihrt werden 
kennen (vgl. PAR{}). Elne derartige Analyse wird auf Basis der 
Betrachtung von AbhSngigkeiten von ICnoten in einem Graphen 
einfach m^glich. Sntsprechende Verf ahren sind nach dem Stand 
der Technik und in der Mathematik per se hlnreichend bek^mnt, 
es soil beispielsweise auf VLIW-Conqpiler und Synthesetools 
verwiesen werden. 

Besondere Beachtiing ben5tigen aber z. B, gegebenenfalls ver- 
schachtelte bedingte Ausftihrungen (IF), da eine korrekte Aus- 
sage der parallel ausftihrbaren Pfade oftmals kaum oder nicht 
zu treffen ist, da eine starke Abhangigkeit vom Werteraum der 
einzelnen Parameter besteht, der oftmals nicht oder nur unzu- 
reichend bekannt ist. Auch kann eine exakte Analyse derart 
viel Rechenzeit in Anspruch nehmen, dafi sie nicht mehr sinn- 
voll durchftlhrbar ist. 
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In derartigen Fallen kann beispielsweise die Analyse durch 
Hinweise vom Prograiimiierer vereinfacht warden und/oder es kann 
anhand entsprechender Compilerschalter derart gearbeitet war- 
den, daft im Zweifelsfall entwqrtier von ainer hohen Paralleli- 
sierbarkeit (ggf. unter V^rschwendimg von ReSsburcen) Oder- von 
einer niederen Parallelisierbarkeit (ggf . unteir: Verschwfendung . 
von Performance) ausgegangen werden soil. 

Ebenfalls kann in diesen Fallen eine empirische Analyse zur 
Laufzeit durchgefOhrt werden. Nach PACTIO, PACT17 sind Verfah- 
ren bekannt, die zur Laufzeit die Erstellung von Statistiken 
Ober das Progranimverhalten erlauben. Derart kann z. B. zu- 
nachst von einer maximalen Parallelisierbarkeit ausgegangen 
Werden. Die einzelnen Pfade geben Meldung^sn an eine Stati- 
stikeinheit (z. B. implement iert in einer CT oder einer ande- 
ren Stufe^vgl. PACTIO, PACT17, grundsStzlich konnen aber auch 
Einheiten nach PACT04 verwenden werden) Ober jeden Durchlauf 
zurtick. Mittels statistischer MaBnahmen ist nunmehr auswert- 
bar, welche Pfade tatsachlich parallel durchlaufen werden. 
Weiterhin ergibt sich die Moglichkeit, anhand der Daten zur . 
Laufzeit zu bewerten, welche Pfade h&ufig oder selten oder nie 
parallel durchlaufen werden. Diese Art der Pfadnutzungsmeldung 
ist nicht zwlngend, aber vortellhaft. 

Dementsprechend kann die Ausf flhrung bei edlnem nSchsten Pro- 
grammaufruf optimiert werden. Dafi dazu die Statistikinformati- 
on insbesondere nichtf Itichtig. wie auf eine Festpiatte wegge- 
schrieben werden kann, sei erwahnt. Aus PACT22, PACT24 ist be- 
kannt, dafl mehrere Konfigurationen entweder zugleich konfigu- 
riert werden konnen tmd danach durch Trigger {PACT08) ange- 
steuert werden oder nur eine Untermenge konfiguriert ist und 
die restlichen Konfigurationen bei Bedarf dadurch nachgeladen 
werden, dafi die entsprechenden Trigger an eine Ladeeinheit 
(CT, PACTIO) gesendet werden. 

Der im folgenden gebrauchte Wert PAR(p) gibt zur Verdeutli- 
. Chung an, welche Parallelitat auf Instruktionsniveau, d. h. 
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wieviel ILP bei einer bestinimten Stufe (p) innerhalb des aus 
der Funktion transfonaierten Datenf luBgraphen erreichbar ist 
(Figur 7a) . 



Gleichfalls bedeutsam ist. Vektbrparallelitat (vgl. VEC{}) . 
Velctorparallelltat ist nutzbar, wenn grofiere Datenmengen zu 
verarbeiten sind. In diesem Fall sind llneare Folgen von Ope- 
rationen veJctorisierbar, d.h. alle Operationen k5nnen gleich- 
zeitig Datenverarbeiten, wobei typischerweise jede separate 
Operation ein separates Datenwort bearbeitet. 

Innerhalb von Schleifen ist dieses Vorgehen teilweise nicht 
mOglich, Daher sind Analysen und Optimierungen notwendig. 
Beispielsweise kann der Graph einer Funktion durch ein Petri- 
netz ausgedrOckt werden. Petri-Netze besitzen die Eigenschaft, 
daB die Ergebnisweitergabe von Knoten kontrolliert erfolgt, 
wodurch beispielsweise Schleifen modelliert werden kdnnen. 
Durch die RQckkopplung des Ergebnisses in einer Schleife wird 
der batendurchsatz bestimmt. Beispiele: 

• Das Ergebnis der Berechnung n wird f Or die Berechnung n+1 

ben&tigt: Nur eine Berechnung kann innerhalb der Schleife 
ausgeftihrt werden. 

• Das Ergebiiis der Berechnung n wird ftir die Berechnung n+m 

bendtlgt: m-1 Berechnungen k5nnen Innerhalb der Schleife 
ausgeftihrt werden. 

• Das Ergebnis bestiimnt den Abbruch der Schleife, geht aber 

nicht in die Berechnung der Brgebnisse ein: Bine Rtick- 
kopplung ist nicht notwendig. Ggf . laufen zwar falsche 
(zuviel) Werte in die Schleifer jedoch kann die Ausgabe 
der Ergebnis se direfct bei Erreichen der Endbedingxong am 
Schleifenende unterbrochen werden. 

Vor der Analyse von Schleifen konnen diese nach dem Stand der 
Technik optimiert werden. Beispielsweise konnen bestimmte In- 
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struktionen aus der Schleife herausgezogen werden und vor oder 
nach die Schleife gestellt werden . 

Der im Folgenden zur Verdeutl4fchung gebrauchte Wert VEC kann* 
den Grad der Vektorisierbarkeit einer Funktion veranschauli- 
Chen. Mit anderen Worten zeigt VEC anV. wieviele. Datenworte zur 
gleich innerhalb einer Menge von Operationen bearbeitet werden 
k5nnen. VEC kann beispielsweise aus der Zahl der bendtigten 
Rechenwerke fOr eine Funktion nnodes und der zugleich innerhalb 
des Vektors berechenbaren Daten Pdata herechnet werden, z.B. 
durch VEC » nnodes / ndata 

1st eine Funktion beispielsweise auf 5 Rechenwerke abbildbar 
(nnodes = 5) und in jedem der Rechenwerke kdnnen zugleich Daten 
bearbeitet werden {ndata - 5) ist VEC = 1 (Figur 7b). 
1st eine Funktion dagegen beispielsweise auf 5 Rechenwerke ab- 
bildbar (nnode3 = 5) und nur in einem Rechenwerk kdnnen jeweils 
Daten bearbeitet werden, z. B, aufgrund einer Rtickkopplung der 
Ergebnisse der Pipeline auf den Eingang (ndata ==5), so ist VEC 
» 1/5 (Figur 7c). 

VEC kann fflr eine gesamte Funktion und/oder far Teilausschnit- 
te einer Funktion berechnet werden. FQr den erfindungsgemSfien 
Cojt^iler kdnnen beide Varlanten vorteilhaft sein, wie generell 
die Bestinnaung und Auswertung von VEC vorteilhaft ist*. 

GeioMB Figur 7a wird PAR(p) far jede Zeile eines Graphen be- 
stimznt, wie vorteilhaft ia5glich. Eine Zeile eines Graphen ist 
dadurch definiert, daB sie innerhalb einer Takteinheit ausge- 
fOhrt wird. Die Anzahl der Operationen ist von der In^lemen- 
tierung der jeweiligen VPD abhSngig. 

Entspricht PAR(p) der Anzahl der Etooten in der Zeile p, so 
kannen alle Knoten parallel ausgefahrt werden. 
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1st PAR{p) kleiner, werden bestimmte Knoten nur alternativ 
ausgefuhrt. Die alternativen Ausftihrungen jeweils eines Kno- 
tens werden in jeweils einer PAE zusaiiHuengefafit * Eine Selekti- 
onsvorrichtiuig ezmaglicht die /T^ktivierung der, dem Status der 
Datenverarbeitung entsprechenden. Alternative zur Laiif zeit wie 
beispielsweise in PACT08 beschrieben. 

VEC wlrd ebenfalls jeder Zeile eines Graphen zugeordnet. 1st 
far eine Zeile VEC - 1, bedeutet dies, daB die Zeile als Pipe- 
linestufe bestehen bleibt. 1st eine Zeile kleiner 1, so werden 
alle nachfolgenden Zeilen, die ebenfalls kleiner 1 sind zusam- 
niengefafit, da ein Pipelining nicht moglich ist. Ehtsprechend 
der Reihenfolge der Operationen werden diese zu eiher Sequenz 
zusammengefafit, die dann in eine PAE konfiguriert wird und zur 
Laufzeit sequentiell abgearbeitet wird. Entsprechende Verfah- 
ren sind beispielsweise aus PCT/DB 97/02949 und/oder PCT/DE 
97/02998 bekannt. 

Durch das beschriebene Verfahren lassen sich durch Gruppierun- 
gen von Sequenzern beliebig komplexe Parallelprozessormodelle 
aufbauen. Insbesondere sind Sequenzerstrukturen zur Abbildung 
von reentrantem Code generierbar. 

Die dazu jeweils notwendigen Synchronisationen kdnnen bei- 
spielsweise durch das in PACT18 beschriebene TimeStamp- 
Verfahren oder bevorzugt durch das in PACT08 beschriebene 
TriggerverfaOiren durchgefOhrt werden. 

Werden mehrere Sequenzer oder sequentielle Telle auf ein PA 
abgebildet, ist es aus Leistungsverbrauchsgrlinden bevorzugt, 
die Leistung der einzelnen Secjuenzer aufeinander abzustiiniaen. 
Dies kann besonders bevorzugt derart geschehen, daB die Ar- 
beitsfrequenzen der Sequenzer aneinander angepaJit werden. Aus 
PACT25 und PACT18 sind beispielsweise Verfahren bekannt, die 
eine individuelle Taktung von einzelnen PAEs oder PAE-Gruppen 
zulassen. 
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Die Frequenz eines Sequenzers kann dabei anhand der Anzahl von 
Zyklen bestimmt werden, die er typischerweise zur Abarbeitung 
der ihm zugewiesenen Funktion /benotigt. 

Bendtigt er belspielsweise 5 Taktzykleh zur Abarbeitung seiner 
Ftihktibri wahrend dais restliche System genau. einen Taktzyklus. 
benatigt, um zugewiesene Aufgaben abzuarbeiten, sollte seine 
Taktung 5-zaal hdher seln als die Taktung des rest lichen Sy- 
stems. Bel einer Vlelzahl von Sequenzem sind jewells unter- 
schiedliche Taktzyklenmaglich. Es kann elne Taktvervielfa- 
Chung und/oder elne Takttellung vorgesehen werden. 

Funktionen werden entsprechend des vorgenannten Verf ahrens 
partitioniert . Beim Partitionieren werden entsprechend Spel- 
cher fur Daten und relevanten Status eingefagt. Weitere alter- 
native und/oder weitergehende Verfahren sind aus PACT13 und 
PACT18 bekannt. 

Manche VPUs bieten nach PACTOl, PACTIO, PACT13, PACT17, 
PACT22, PACT24 die MSglichkeit der differentiellen Rekonfigu- 
ration. Diese kann angewendet werden, wenn nur verhSltnismafilg 
wenige Anderungen innerhalb der Anordnung von PAEs bei einer 
Rekonfiguratlon no.twrendig werden. Mit anderen Worten werden 
nur die VerSnderungen einer Konfiguration gegenllber der aktu- 
ellen Konfiguration rekbnflguriert. Die Partitionlerung kann 
in dlesem Fall 'dergestalt seiii, daB die auf eine Konfiguration 
folgenden (differentielle) Konfiguration nur die notwendigen 
Rekonfigurationsdaten enthalt und kelne vollstSndige Konfigu- 
ration darstellt. Der Con^iler der vorliegenden Erfindung ist 
bevorzugt dazu ausgebildet, dies zu erkennen und zu untersttit- 
zen. 

Das Scheduling der Rekonfiguratlon kann durch den Status er- 
folgen, der Funktion (en) an eine Ladeeinheit (CT) meldet, wel- 
che ihrerseits auf Basis des eingehenden Status die n^chste 
Konfiguration oder Teilkonfiguration auswahlt und konfigu- 
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riert. Im Detail sind derartige Verfahren aus PACTOl, PACT05, 
PACTIO, PACT13, PACT 17 bekannt- 

Weiterhin kann das Scheduling die Moglichkeit des Vorladens 
von Konfigurationen wahrend d^ Lauf zeit. einer anderen Kohfi- 
guration unterstfitzen. Dabei kSnnen metoere Konifigurationen. 
mbgMcherweise auch spefculativ vbrgeladeh Werdehi- .d..h. ohne 
daB sichergestellt ist, daB die Konfigurationen (U^erhaupt be- 
n5tigt werden. Dies ist besonders dann bevorzugt, wenn die CT 
etwa bei ISngeren, konfigurationsfrei abarbeitbaren Datenstr5- 
men zuBcdndest weitgehend unbelastet ist. und insbesondere nicht 
Oder nur wenig aufgabenbelastet ist. Durch Selektionsmechanis- 
men wie etwa nach DE 197 04 728.9 werden dann zur Laiifzeit die 
zu verwendenden Konfigurationen ausgewMhlt (siehe auch Bei- 
spiel NLS in PACT22/24) • 

Ebenfalls konnen die lokalen Sequenzer durch den Status ihrer 
Datenverarbeitung gesteuert werden^ wie etwa aus DE 196 51 
075.9-53, DE 196 54 846.2-53, DE 199 26 538,0 bekannt. Zur 
DurchfOhrung ihrer Rekonf iguration kann ein weiterer abhSngi- 
ger oder unabh^giger Status an die CT gemeldet werden (siehe 
beispielsweise PACT04/ LLBACK). . 

Das Vorstehende wird nun mit Bezug auf weitere Figuren be- 
schrieben. Dabei werden im folgenden fplgeoide Zeichen zur Ver- 
einfachung der Schreibung verwendet: v oder, a und. 

Fignr 8a zeigt die Abbildung des Graphens nach Fig. 7a auf ei- 
ne Gruppe von PAEs bei maximaler erreichbarer Parallelitat. 
SSmtliche Operationen (Instruktion il-il2) sind in einzelne 
PAEs abgebildet. 

Figur 8b zeigt denselben Graphen, beispielsweise icdt maximaler 
nutzbarer Vektorisierbarkeit. Jedoch sind die Mengen von Ope^ 
rationen V2={il, i3}, V3=={i4, 15, 16, 17, 18}, V4={i9, ilO, 
ill} nicht parallel par (par {{2,3, 4})= 1. Damit lassen sich 
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Ressourcen einsparen, indem jeweils eine Menge P2, P3, P4 von 
Operationen einer PAE zugeordnet wird. Bin Statussignal zu je- 
dein Datenwort in jeder Stufe w^hlt die auszufahrende Operation 
in der jeweiligen PAE aus. DieT PAEs sind als Pipeline (Vektor) 
vernetzt und jede PAE fuhrt je Takt eine Operation iiber je- 
weils unterschiedliche Datenwort aus. 

Es ergibt sich folgender Ablauf : 

PAEl berechnet Daten und gibt diese an PAE2 weiter. Zusammen 
mit den Daten gibt sie ein Statussignal weiter, das anzeigt, 
ob il Oder 12 ausgefOhrt werden soil. 

PAE2 berechnet die Daten von PAEl weiter. Entsprechend des 
elilgehehden Statusslgnals wird die auszuftihrende Operation 
(il, 12) ausgewShlt und berechnet. Entsprechend der Berechnung 
gibt PAE2 ein Statussignal an PAE3 weiter, das anzeigt, ob (14 

V 15) V (16 V 17 V 18) ausgefOhrt werden soil. 

PAE3 berechnet die Daten von PAE2 weiter. Entsprechend des 
eingehenden Statusslgnals wird die auszufdhrende Operation (14 

V 15) V (16 V 17 V 18) ausgewahlt und berechnet. Entsprechend 
der Berechnung gibt PAE3 ein Statussignal an PAE4 welter, das 
anzeigt ob 19 v ilO v ill ausgefiihrt werden soil. 

PAE4 berechnet die Daten von PAE3 weiter. Entsprechend des 
eingehenden Statusslgnals wird die auszufiihrende Operation 19 

V 110 V ill ausgewahlt und berechnet. 
PAE5 berechnet die Daten von PAE4 weiter. 

Ein mogliches entsprechendes Verfahren und Hardware, die eine 
besonders gtinstige Umsetzimg des beschrlebenen erlaubt, 1st in 
DE 197 04 728.9 (Figuren 5 und 6) beschrieben; auch PACT04 und 
PACTIO, PACT13 beschreiben allgemeln nutzbare, jedoch aufwen- 
digere Verfahren. 

Figar 8c zeigt wiederum denselben Graphen. In dlesem Beisplel 
ist eine Vektorisierung nicht mOgllch, jedoch ist PAR(p) hoch. 
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was bedeutet, dafi innerhalb einer Zeile jeweils eine Vielzahl 
von Operationen gleichzeitig ausgefuhrt werden kann. Die 
parallel durchfiihrbaren Operationen sind P2 = {il a 12};- P3 = 
.{14 A 15 A 16 A 17 A 18}, P4 =^ {19 a 110 a ill}. Die PAEs slnd 
derart vernetzt, daB sie beliebige Daten belleblg unterelnan- 
der austauschen kOnnen. Die einzelnen PAEs ftihren nur dann 
Operationen durch, wenn im entsprechenden Zyklus ein ILP be-* 
steht, ansonsten verhalten sie slch neutral (NOP), wobei ggf. 
Heruntertaktung und/oder eine Takt- und/oder Stromabschaltung 
zur Mihimierung' der Verlustleistung elrfolgen kann. 
Es ist dabei fplgender flblauf vorgesehen: 

Im ersten Zyklus arbeitet nur PAE2 and gibt die Daten an PAE2 
und PiUBS weiter- 

Im zveiten Zyklus arbeiten PAE2 und PAE3 parallel und geben 
ihre Daten an PAEl, PAE2, PAE3, PAE4, PAES welter. 
Im drltten Zyklus arbeiten PAEl, PAE2, PAES, PAE4, PAES und 
geben die Daten an PAE2, PAES, PAES weiter. 

Im vierten Zyklus arbeiten PAE2^ PAE3, PAES und geben die Da- 
ten an PAE2 weiter. 
Im ^Gnften Zyklus arbeitet nur PAE2. 

Die Funktion benfitigt somit S Zykleh zur Berechnung. Der ent- 
sprechende Sequenzer. sollte also mit dem' 5-£achen Talct im Ver- 
bal tnis zu seiner Umgebung albeit en> urn. eine ent sprechende 
Performance zu erzielen. 

Eln magliches entsprechendes Verfahren 1st in PACT02 (Figuren 
19, 20 und 21) beschrieben; auch PACT04 und PACTIO, 13 be- 
schreiben allgemein nutzbare, jedoch aufwendigere Verfahren. 
Weitere Verfahren und/oder Hardware sind verwendbar. 

Figur 8d zeigt den Graphen nach Fig. 7a far den Fall, daB kei- 
nerlei nutzbare Parallelitat besteht. Zur Berechnung elnes Da- 
tenwortes mufi jede Stufe nacheinander durchlaufen werden. In- 
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nerhalb der Stufen wird immer nur genau einer der Zweige ver- 
arbeitet . 

Die Funktion benotigt ebenfalls 5 Zyklen zur Berechnung, cyl = 
(il), cy2 « (12 V 13)/ cy3 = (i4 v 15 v 16 v 17 v 18), cy4 = 
(19 V 110 V 111), cy5 = (112) . Der entsprechende Sequehzer 
sollte also mlt dem 5-fachen Takt Ira Verhaltnls zu seiner Urn- 
gebung arbelten, urn elne entsprechende Performance zu erzle- 
len. 

Bine derartige Funktion ist beispielswelse Mhnlich Fig. 8c 
durch einen einfachen Sequenzer hach PACT02 ( Figuren 19, 20 
und 21).abbildbar. Auch FACT04 \md PACTIO, 13 beschreiben all- 
gemein nutzbare, jedoch aufwendigere Verfahren. 



Die in Figur 8 dargestellten Abblldungen sind beliebig misch- 
bar und gruppierbar. 

In Figur 9a 1st belspielswelse dleselbe Funktion dargestellt, 
bel welcher die Pfade (12 a (14 v 15) a 19) und (13 a (16 v 17 
V 18) A (19 V ilO)) parallel ausfiihrbar slnd. (14 v 15) , 16 v 
17 V 18), (19 V 110) slnd jewells alternatlv. Die Funktion 1st 
welterhln vektorlslerbar. Damit last slch elne Pipeline auf- 
bauen, in welcher far 3 PAEs (PAE4, PAE5, PAB7) jewells anhand 
von Statusslgnalen die jeweilig auszuftihrende Funktion be- 
stinnat 1st. 

Figur 9b zeigt ein Shnliches Beispiel, bei dem eine Vektorl- 
slerung nicht mdglich ist* Allerdlngs sind die Pfade 
(11 A 12 A (14 V 15) A 19 A il2) und (13 a (16 v 17 v 18) a 
(110 V 111)) parallel.. Damit laat slch die optlmale Perfor- 
mance durch den Elnsatz von zwei Pi^s erzlelen, die bel die 
parallelen Pfade auch parallel abarbeiten. Die Synchronisation 
der PAEs untereinander erfolgt durch Statussignale, die vor- 
zugswelse von PAEl generiert werden, da diese den Beginn (11) 
und das Ende (il2) der Funktion berechnet. 
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Es soli besonders darauf hingewiesen werden, daft sich aus ei- 
ner mehrfachen Anordniing von Sequenzern ein symetrisch paral- 
leles Prozessormodell (SMP) odfer fihnliche^ heute yexwendete 
Mehrprozessorinodelie ergeben kOimeh. 

Weiterhin soli darauf hingewiesen werden, daB Scimtllche Konfl- 
gurationsregister ffir das Scheduling auch im Hintergrund 
und/oder wahrend der Datenverarbeitung mit neuen Konfiguratio- 
nen geladen werden konnen. 

Es ist dies etwa moglich, wenn die Hardware wie nach DE 196 51 
075.9^53 bekannt aufgebaut ist. Es stehen dann unabhangige 
Speicherbereiche oder Register zur VerfQgung, die unabhangig 
angesprochen werden konnen* Auf bestimmte Stellen wird durch 
eingehende Trigger gesprungen, ebenfalls kann mittels Sprung- 
befehlen (OMP, CALL/RET) , die ggf . auch bedingt durchfiihrbar 
sind gesprungen werden. 

GemSlB DE 196 54 846.2-53 stehen unabhangige Schreib- und Lese- 
zeiger zur Verfagung, wodurch grundsatzlich eine Unabhangig- 
keit und somit die Mdglichkeit des Zugrif fes im Hintergrund 
gegeben ist. Insbesondere ist es mdglich, die Speicher zu seg- 
mentieren, wodurch eiiie zusatzliche Unabhangigkeit gegeben 
ist. Mittels Sprungbefehlen (JMP, CALL/RET), die ggf. auch be- 
dingt durchfiihrbar sind, kann gesprungen werden. 

Nach DE 197 04 728.9 sind die einzelnen Register, die durch 
die Trigger gewahlt werden kSnnen, grundsStzlich unabhangig 
und erlauben daher eine unabhangige Konfiguration, insbesonde- 
re iia Hintergrund. Sprilnge innerhalb der Register sind nicht 
mSglich, die Auswahl erfolgt ausschlieBlich tiber die Trigger- 
vektoren. 
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Ein wesentlicher Faktor zur Bewertung der Effizienz von PAR 
und VEC ist die Art der Daten die durch die jeweilige Struktur 
verarbeitet werdeh. Beispielsweise ist es lohnen eine Struktur 
auszuwalzen, also zu pipellneif und oder parallelisieren, die 
eine groBe Meiige von Datian verarbeitet; Wie es z.B. bei Video- 
daten odef Telekomdaten der Fall ist. Strukturen die weiiige 
Daten verarbeiten (z.B. Tastatureingabe, Maus, etc.) lohnen 
sich nicht ausgewalzt zu werden, im Gegenteil sie wOrden nur 
anderen Algorithmen die Ressourcen blockieren. 

Soiait wird vorgeschlagen anhand unterschiedlicher Hinweise nur 
die Algorithmen, Strukturen oder Telle von Algorithmen zu par- 
allelisiem und vektorisieren, die entsprechend grofie Daten*- 
mengen Verarbeiten. 

Derartige Hinweise konnen beispielsweise sein: 
1- Der Datentyp (Arrays, Streams sollten z.B. aufgrund der ho- 
hen Datenmenge eher ausgewalzt werden als z.B. einzelne Zei- 
chen) . 

2. Die Art des Zugriffes (llneare Programmabfolgen sollten 
z.B. in Sequenzer abgebildet werden, wShrend Schleifen sich 
z.B. aufgrund der hohen Anzcdil von DurchlSufen zum Auswalzen 
lohnen. 

3. Die Art der Quelle und/oder de.s Ziels (Tastatur und Maus 
haben z.B. eine zu geringe Datenrate. um effizient ausgewalzt 
zu werden, dagegen ist z.B. die Datenrate bei Netzwerk 
und/oder Video Quellen oder Zielen deutlich hc^her) . 

Fiir die Analyse kdnnen dabei eine beliebige Menge dieser Hin- 
weise hinzugezogen werden. 



7. Segriffsdefinition 
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Zustand, der nur innerhalb ei- 
ner bestimmten Konf iguration 
relevant ist; 

Zustaiidr der in mehreren Kon- 
figurationen relevant ist und 
zwischen den Konf igurationen * 
ausgetauscht werden mtiB; 

Zustand, der Innerhalb eines 
Algorlthmus zu dessen korrek-* 
ter AusfOhruiig dessen benStigt 
wird und somit durch den Algb- 
rithmus beschrieben ist und 
davon verwendet wird; 

Zustand, der fur den eigentli- 
Chen Algorithmus ohne Bedeu- 
tung ist und auch nicht im Al- 
gorithmus beschrieben ist, der 
jedoch von der ausfOhrenden 
Hardware iinplementierungscJ:>- . 
hangig bendtigt wird 



giiobaJ. reievanter Zustand 



relevanter Zustand 



irxelevanter Znstand 
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1. Verfahren zuia Obersetzen ijbn Hochsprachen auf rekonfigu- 
rierbare Architelctureri, dadurch gekennzeichnet, dafi ein 
endllGher Autoniat zur Ber.echnung dera^ aufgebaut wird, dafi . 
ein komplexes kombinatorisches Netz aus einzelnen Funktio- 
nen gebildet wird und dem Netz Speicher zur Speicherung der 
Operanden und Brgebnissen zugeordnet sind. 

2. Verfahren ztuw Datenbe- und/oder verarbeitung mit einem mul- 
tidimensionaien Feld mit rekonfigurierbaren ALUs, dadurch 
gekennzeichnet/ daB ein Hochsprachencode vorgesehen und 
derart tibersetzt wird, dafi ein endlicher Automat zur Be-, 
rechnung aufgebaut wird, wobei ein komplexes kombinatori- 
sches Netz aus einzelnen Funktionen gebildet und dem Netz 
Speicher zur Speicherung der Operanden und/oder Ergebnisse 
zugeordnet werden. 

3. Verfahren nach einem der vorhergehenden AnsprQche/ dadurch 
gekennzeichnetr daB das kon^lexe kombinatorische Netz so 
aufgebaut und/oder zerlegt wird, daB die PAB-Matrix m6g- 
lichst lange ohne Rekonfiguration betrieben wird. 

4. Verfahren nach dem vorhergehenden Anspruch, dadurch gekenn- 
zeichnet, daB komplexe Instruktionen bestimmt werden, um 
das komplexe kombinatorische Netz so aufzubauen und/oder zu 
zerlegen, daB die PAE-Matrix mSglichst lange ohne Rekonfi- 
guration betrieben wird- 

5. Verfahren nach einem der vorhergehenden AnsprUche, dadurch 
gekennzeichnet, daB ein endlicher Automat direkt aus impe- 
rativem Quelltext aufgebaut wird. 
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6. Verfahren nach einem der vorhergehenden AnsprUche, dadurch 
gekennzeichnet, daS> ein endlicher Automat aus an grobgranu- 
lare Logikkreise und/oder an vorhandene f eingranulare Ble- 
mente (FPGA-Zellen in der/VPU, stateitiachines etc.) angepaJB- 
te Operationen aufgebaut wird, irisbesondere ausschliefilich 
an solche. 

7. Verfahren nach elnem der vorhergehenden AnsprUche, dadurch 
gekennzeichnet, dafi ein endlicher Automat dann in Konfigu- 
rationen zerlegt wird. 

8. Verfahren nach einem der vorhergehenden AnsprUche, dadurch 
gekennzeichnet, dafi generierte Konfigurationen succesive 
auf die PAE-Matrix abgebildet warden und Arbeit sdaten 
und/oder Zustande, die zwischen den Konfigurationen zu 
abertragen sind, in Speicher abgelegt werden. 

9- Verfahren nach dem vorhergehenden Anspruch, dadurch gekenn- 
zeichnet, dafi der Speicher vom Compiler bestimmt bezie- 
hungsweise vorgesehen wird. 

10. Verfahren nach dem vorhergehenden Anspruch, dadurch gekenn- 
zeichnet, daB wahrend einer Koinfiguration Daten aus einer 
VPO externen Quelle und/oder einem inteinien Speicher verar- 
beitet und an eine exteme Ctuelle und/oder einen intemen 
Speicher geschrieben werden. 

11 • Verfahren nach einem der vorhergehenden Iknspriiche, dadurch 
gekennzeichnet, dafi ein Speicher fUr einen gesamten Daten- 
satz vorgesehen wird, der umfangreicher als ein einzelnes 
Datenwort ist. 

12. Verfahren nach einem der vorhergehenden Ansprflche, dadurch 
gekennzeichnet, dafi bei Verarbeitung einer ablaufenden Kon- 
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figuration Daten compilerbestiiraat in die Speicher abgelegt 
werden. 

13. Verfahren nach einem der vbrhergehenden AnsprQche, dadurch 
gekennzeichnet^ da& ein Speicher fur Operanden;, ein Spei- 
cher fClf Ergebnisse und ein Netzwerk aus Zuweisuhgen 
und/oder Vergleichen-Anweistmgen, also Bedihgungen wie z.B. 
IF, CASE, Schleifen (WHILE, FOR, REPEAT) sowie optionalen 
Adressgenerator (en) zur Ansteuerung der Speicher mit dem 
Automaten vorgesehen werden. 

14. Verfahren nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, dafi ZustSnden wie ^rforderlich Speicher zu- 
geordnet werden, und hierbei zwischen algorithmisch rele- 
vanten und irrelevanten ZustSnden unterschieden wird, ins- 
besondere solchen relevanten Zustanden, die innerhalb des 
Algorithmus notwendig um dessen korrekte Funktion zu be- 
schreiben und solchen irrelevante Zust^nde, die durch die 
verwendete Hardware und/oder die gewdhlte Abbildung oder 
aus anderen sekundSren Grtinden entstehen. 



15. Verfahren nach einem der vorhergehenden Ansprache, dadurch 
gekennzeichnet, daB Load/Store Opera tionen tinter Vorsehen 
elner extemen Adressierung, also des Datentransfers. mit 
extemen Baugruppen und einer interne Adressierung, also 
die Oatentransfers zwischen PAEs, i.b. zwischen RAM-PAEs 
und ALU- PAEs vorgesehen werden. 



16. Verfahren nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, daB bei der Datenverarbeitung eine erste 
Konfiguration entfernt wird und die zu sichernden Daten in 
entsprechenden Speichem (REG) (Speicher, Register, Zahler, 
etc) verbleiben. 
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17. Verfahren nach einem der vorhergehenden Ansprtlche, dadurch 
gekennzeichnet, daB die erste Konfiguration wieder geladen 
wird und auf die zuvor gesicherterten, ihr zugeordnete Da- 
ten zugreift. 

18. Verfahren nadh einem der vorhergehenden Ansprttche, dadurch 
gekennzeichnet/ daB fttr den Zugrif f auf zuvor gesicherterte 
Daten eine zweite Konfiguration geladen wird, die die REG 
in geeigneter Weise und def inierter Reihenfolge mit einem 
Oder mehreren globalen Speicher{n) verbindet, insbesondere, 
urn unter Verwendung von Adressgeneratoren auf den/die glo- 
balen Speicher zuzugreifen, wobei der Adressgenerator die 
Adresseh fixe den/die globalen Speicher (n) bevorzugt derart 
generiert, dass die beschriebenen Speicherbereiche (POSHA- 
REA) der entfernten ersten Konfiguration eindeutig zugeord- 
net werden konnen. 

19. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, da& automatisch Transformation zur Repre- 
sentation der Parallelisier- bzw. Vektorisierbarkeit (Par- 
Vec-Transformation) d\irchgefiihrt werden und/oder VEC und 
PAR-Anteile als Petri-Netz ausgestaltet werden, um wie be- 
vorzugt die Weiterverarbeitung nach konqpletter Verarbeitung 
der jeweiiigen Inhalte zu steuem. 

20. Verfahren nach einem der vorhergehenden Ansprttche, dadurch 
gekennzeichnet, da5 

arithmetisch/logische Befehle direkt in das kombinatorische 
Netz abgebildet werden und/oder 

Sprtlnge (Jump/Call) entweder direkt in das kombinatorische 
Netz ausgewalzt und/oder durch Rekonfiguration realisiert 
werden und/oder 

Bedingungen und Kontrollf luBbefehle (if, etc) entweder im 
kombinatorischen Netz vollstSndig aufgeiast und /oder bear- 
beitet werden und/oder an eine Obergeordnete Konfigurati- 
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onseinheit weitergeleitet werden, die sodann entsprechend 
des entstandenen Status eine Rekonfiguration durchfiihrt 
und/oder 

Load/Store-pperationen in /Separate Konfigurationen abgebil- 
det und/bdef dutch Adressgeneratdren realisieirt werderi, die 
internen Speichei: ;(REG{ }) MttelS: Adressgeneratoren in ex- 
terna Speicher schreiben und/oder diese von externen Spei- 
chem und/oder Peripherie laden und/oder 
Register-Move-Operationen im kombinatorischen Netz durch 
Busse zwischen den internen Speichem (REG{}) realisiert 
warden und/oder 

Push/Pop-Operationen durch separate Konfigurationen reali- 
siert werden, die bestiromte interne Register im Jcombinato- 
rischen Netz und/oder die internen Speicher (REG{)) mittels 
Adressgeneratoren in externe Speicher schreiben oder aus 
externen Speichem lesen und die bevorzugt vor oder nach 
den eigentlichen datenverarbeitenden Konfigurationen ausge- 
fOhrt werden. 
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